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The  Use  of  ASN.1  and  XDR 
for  Data  Representation 
in  Reai-Time  Distributed  Systems 


Abstract:  This  report  provides  an  overview  of  two  standards  that  are  used  for 
data  specification  and  representation  in  distributed  systems.  The  standards  con¬ 
sidered  are  the  Abstract  Syntax  Notation  One  (ASN.1)  and  the  external  data  rep¬ 
resentation  (XOR).  Standards  for  data  representation  are  appropriate  for  the  de¬ 
velopment  of  real-time  distributed  systems,  particularly  loosely  coupled,  heteroge¬ 
neous  systems.  The  report  presents  an  example  of  the  use  of  each  standard. 
Several  performance  metrics  are  also  introduced  that  are  suitable  for  comparing 
the  space  and  time  costs  of  using  the  different  standards.  Several  issues  are  dis¬ 
cussed  that  are  appropriate  to  a  system  designer.  An  Ada  implementation  of 
ASN.1  encode  and  decode  routines  for  floating  point  types  is  included  in  an  ap¬ 
pendix. 


1.  Introduction 

Hard  real-time  systems  are  characterized  by  the  presence  of  timing  deadlines  that  must  be 
met  to  assure  system  correctness.  In  the  case  of  a  distributed  system,  the  deadlines  are 
often  characterized  as  end-to-end  deadlines  that  involve  multiple  application  programs.  In 
the  process  associated  with  an  end-to-end  deadline,  a  sending  application  encodes  data  in 
some  structure  that  a  receiving  application  is  able  to  decode.  In  the  case  of  hard  deadlines, 
performance  of  a  system  in  regard  to  data  manipulation  is  an  important  issue,  particularly 
when  the  system  can  be  composed  of  heterogeneous  machines. 

This  report  examines  two  well-known  standards  for  data  specification  and  representation, 
namely 

•  The  Abstract  Syntax  Notation  One  (ASN.1).  ISO/IEC  8824  [2]  defines  the  speci¬ 
fication  of  ASN.1,  while  ISO/IEC  8825(3]  defines  the  basic  encoding  rules 
(BER)  that  are  used  in  the  representation  of  data. 

•  The  external  data  representation  (XDR),  defined  in  reference  [4]. 

The  orientation  of  this  report  is  more  toward  the  methods  used  to  represent  as  opposed  to 
specify  data.  For  our  purposes,  data  representation  involves  the  encoding  and  decoding  of 
data,  usually  for  transfer  between  system  elements.  Data  specification  involves  the  use  of 
some  type  of  abstract  syntax  to  describe  data.  While  these  are  clearly  related,  we  are  con¬ 
cerned  more  with  the  manner  in  which  data  is  encoded  and  decoded  by  elements  of  a  distri¬ 
buted  system. 

This  document  is  organized  as  follows:  Chaqpter  2  presents  an  overview  of  the  problems 
addressed.  Chapter  3  provides  an  overview  of  the  ASN.1  basic  encoding  rules.  The  use  of 
the  external  data  representation  is  considered  in  Chapter  4.  A  comparison  of  these  two 
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approaches  is  then  discussed  in  Chapter  5.  which  aiso  contains  a  discussion  of  issues  re¬ 
lated  to  the  two  standards.  A  brief  summary  of  the  report  appears  in  Chapter  7.  Throughout 
this  report,  we  use  a  representative  examp)le,  that  of  a  track  update  message,  to  illustrate 
the  various  possible  encodings.  Appendices  A  and  B  contain  the  BNF  specifications  for 
ASN.1  and  XOR,  respectively.  Appendix  C  contains  an  example,  written  in  Ada,  of  ASN.1 
encode  and  decode  routines. 

The  work  reported  in  this  docume  t  was  performed  by  the  Open  Systems  Architecture  Proj¬ 
ect  at  the  Software  Engineering  i/istitute  (SEI).  The  SEI  is  a  federally  funded  research  and 
development  center  operated  by  Carnegie  Mellon  University  under  contract  to  the  Depart¬ 
ment  of  Defense.  This  work  was  supported  in  part  by  the  Navy  Next  Generation  Computer 
Resources  Program. 
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2.  Overview 


2.1.  Problem  Considered 

A  typical  communication  mechanism  used  in  distributed  systems  is  a  remote  procedure  call 
(RPC).  This  is  illustrated  in  Figure  2-1.  The  client  makes  a  request  (a  call)  to  a  server.  Part 
of  the  request  is  an  indication  of  the  procedure  to  be  called.  The  server  performs  the  re¬ 
quested  operation  and  then  returns  a  response  to  the  client,  completing  the  procedure  call. 
Note  that  RPC  may  be  implemented  either  synchronously  or  asynchronously. 


Request 


Figure  2<1 :  Model  of  a  Remote  Procedure  Call 

The  data  exchanged  in  an  RPC  consists  of  two  parts,  as  indicated  in  Figure  2-2.  The  first  is 
a  protocol-specific  component  that  conveys  information  about  the  protocol  being  used.  For 
example,  in  the  case  of  the  Sun  RPC  [5]  the  protocol  component  contains 

•  An  identifier  that  uniquely  associates  calls  and  responses. 

•  A  body  that  can  be  either  a  call  body  or  a  reply  body.  In  the  case  of  a  call,  for 
example,  the  call  body  may  contain  the  RPC  version  number,  remote  program 
number,  remote  program  version  number,  remote  procedure  number,  and  au¬ 
thentication  information. 


Protocol  Component 


Data  Component 


Figure  2-2:  Encapsulation  of  Protocol  Information 

The  second  component  of  the  information  transferred  is  a  data  component  that  contains  the 
information  to  be  passed  in  the  remote  procedure  call.  In  the  case  of  the  Sun  RPC  [5]  and 
the  Versatile  Message  Transaction  Protocol  (VMTP)  [6],  the  data  component  is  represented 
using  the  XDR  standard  [4]. 
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There  are  several  performance  issues  to  consider  in  the  use  of  a  RFC  model.  Of  concern  in 
this  report  is  the  mechanism  that  is  used  to  encode  (and  decode)  the  data  component  of  the 
RPC.  Application  programs  require  flexible  representatio.ns  that  are  also  efficient  in  their  en¬ 
codings.  Frequently,  however,  greater  flexibility  of  data  representations  implies  a  more 
complicated  representation,  which  in  turn  requires  more  complicated  encode  (and  decode) 
routines.  These  more  complicated  routines  are  larger  and  require  more  processing  time  to 
execute.  As  we  shall  see,  the  notions  of  flexibility  and  efficiency  are  not  necessarily  com¬ 
patible. 


2.2.  Role  of  Standards 

There  is  a  current  trend  toward  the  increased  use  of  standards  in  DoD  real-time  systems 
developments.  It  is  hoped  that  the  use  of  standards  will  increase  system  interoperability. 
When  a  standard  contains  more  attributes  than  are  believed  necessary  for  the  real-time 
domain,  a  profile  of  the  standard  can  be  developed.  For  example,  an  embedded  system 
may  not  need  all  the  functionality  of  a  standard  for  a  general  purpose  operating  system. 

Dkata  representation  standards  such  as  ASN.1/BER  and  XDR,  which  are  considered  in  this 
report,  are  appealing  in  that  they  lend  themselves  to  automatic  code  generation.  For  ex¬ 
ample,  one  may  create  a  data  specification  and  then  use  a  tool  to  automatically  generate 
the  routines  to  encode  and  decode  the  data.  The  existence  of  such  a  tool  would  eliminate 
the  need  for  hand-coding  the  encode  and  decode  operations  on  data  structures. 


2.3.  An  Example 

A  typical  requirement  of  a  real-time  system  is  the  need  to  perform  track  management.’’  We 
will  consider  the  example  of  a  track  update  message  that  can  be  exchanged  by  components 
of  a  distributed  system.  This  example  will  be  used  throughout  this  report  to  illustrate  the  use 
of  different  data  representation  and  encoding  schemes. 

2.3.1.  Specification 

A  track  update  message  can  be  transmitted  when  information  about  some  track  changes,  or 
on  a  periodic  basis.  Typically,  this  message  would  contain  the  following  information: 

•  Message  length:  the  number  of  words  in  the  message  (we  assume  a  16-bit 
word). 

•  Message  ID:  a  unique  identifier  for  the  class  of  the  message. 

•  Track  index:  a  unique  identifier  of  the  track  being  reported. 

•  Positional  information:  the  location  of  the  track  in  some  particular  coordinate 
system. 


track  represents  the  set  of  information  about  an  object  in  the  external  environment,  such  as  a  radar  report 
of  an  aircraft. 


4 


CMU/SEI-93-TR-10 


•  Velocity  information:  the  velocity  components  of  the  track.  Note  that  these 
components  may  be  reported  in  a  different  coordinate  system  than  that  used  to 
specify  the  track  position. 

•  Track  category:  an  indication  of  the  type  of  track,  such  as  an  air  or  surface 
track. 

•  Maneuver  indicator:  an  indication  that  the  track  is  maneuvering.  This  informa¬ 
tion  is  used  in  certain  algorithms  that  estimate  the  state  of  the  track. 

•  Track  quality:  a  measure  of  the  quality  of  the  position  and  velocity  information 
contained  in  the  message. 

•  Sensor:  an  indication  of  the  sensor  that  is  reporting  the  information.  Typically, 
many  sensors  may  be  available,  and  it  Is  necessary  to  know  which  isarticular 
sensor  is  reporting  the  data. 

•  Clock:  the  time  at  which  the  track  data  was  collected. 

In  reality,  typical  systems  may  report  more  information  than  that  listed  above.  For  our  pur¬ 
poses.  however,  the  above  list  captures  the  essence  of  the  data  and  will  serve  to  illustrate 
the  issues  associated  with  data  representation.  Although  presented  in  the  context  of  a  mes- 
sap«)  iKUrchange.  the  model  may  easily  be  extended  to  an  RPC  model  where  the  requested 
funcTioii  Is  io  update  a  remote  track  database. 

2.3.2.  Representation 

The  information  that  appears  in  the  track  update  message  is  formatted  in  a  predefined  man¬ 
ner  as  specified  in  some  interface  requirements  specification  (IRS).  The  IRS  specifies  not 
only  the  format  of  the  data,  but  the  permitted  range  of  values  of  the  message  components 
and  other  information  about  the  communication  protocol  that  is  used  between  systems  that 
exchange  such  data. 

A  typical  representation  of  a  track  update  message  appears  in  Figure  2-3.  The  following  are 
to  be  noted  about  the  data  representation: 

•  The  number  of  words  (NW)  is  a  constant,  having  the  value  12  (decimal),  and  is 
contained  in  one  byte. 

•  The  message  ID  (MID)  is  a  constant,  having  the  value  202  (octal),  and  is  con¬ 
tained  in  one  byte. 

•  The  track  index  is  represented  as  an  unsigned  integer  having  range  1  to  7777 
(octal). 

•  The  X-Position  (X)  and  Y-Position  (Y)  are  fixed-point  types  with  the  assumed 
(binary)  decimal  point  located  between  bits  6  and  7  (we  assume  bits  are  num¬ 
bered  from  right  to  left  starting  with  0).  The  units  for  these  quantities  are  in  data 
miles.2  and  the  range  is  [-255  H,  255  i^]. 

•  The  height  is  a  fixed-point  type  with  the  assumed  (binary)  decimal  place  be¬ 
tween  bits  7  and  8.  The  height  is  reported  in  units  of  data  miles  and  is  in  the 
range  [0. 255 


^ne  data  mile  is  defined  to  be  6000  feet. 
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Hgure  2-3:  Structure  of  Track  Update  Message 

•  The  velocity  data  is  a  fixed-point  type  with  the  assumed  (binary)  decimal  place 
between  bits  12  and  13.  Velocity  data  is  reported  in  units  of  data  miles  per  sec¬ 
ond  and  is  within  the  range  [0, 

•  The  track  category  (CAT)  is  a  Boolean;  if  TRUE,  it  indicates  a  surface  track; 
othenATise,  it  indicates  an  air  track. 

•  The  maneuver  {MWR)  is  represented  as  a  Boolean;  if  TRUE,  it  indicates  that  the 
track  is  maneuvering. 

•  The  track  quality  occupies  one  byte  and  is  represented  by  an  integer  in  the 
range  from  0  to  1 00  with  larger  values  denoting  higher  track  qualities. 

•  The  sensor  source  is  1 0  bits  wide,  with  each  bit  indicating  a  particular  sensor. 
For  example,  if  bit  6  is  set,  the  track  data  is  being  reported  by  sensor  6,  which 
we  will  label  as  SENSOR_Q. 

•  The  clock  is  an  unsigned  integer  value  of  the  time  that  the  data  was  collected. 


NW 


MID 


TRACK  INDEX 


HEIGHT 


X-VELOCITY 


Y-VELOCITY 


Z-VELOCITY 


M 

V 

R 


TRACK  QUALITY 


SENSOR  SOURCE 


CLOCK  (Upper) 


CLOCK  (Lower) 
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The  time  is  reported  in  milliseconds  in  the  range  [0,  21777777777]  octal.  Note 
that  the  high-order  bit  is  used  for  data,  not  a  sign. 

There  are  two  points  about  the  representation  of  the  track  update  message  that  are  worth 
noting.  First,  the  representation  seeks  to  minimize  the  amount  of  storage;  for  example,  the 
track  category  and  maneuver  request  bits  are  packed  in  a  byte  and  the  sensor  is 
represented  as  an  array  of  type  Boolean,  which  is  also  packed.  Second,  note  the  number  of 
fixed-point  types  that  are  contained  in  the  message. 

The  packing  of  data  and  the  use  of  fixed-point  types  are  typical  of  many  existing  systems. 
This  is  in  part  due  to  concern  over  buffer  management  (perhaps  at  the  expense  of  additional 
processing  time  to  decode  and  encode  a  message).  The  prevalence  of  fixed-point  types  is 
frequently  driven  by  hardware  considerations;  that  is,  data  is  presented  directly  from  a 
hardware  device. 

Finally,  let  us  consider  an  instance  of  a  track  update  message.  Assume  that  track  index  165 
(decimal)  is  reported  at  a  position  given  by  (100.5,  67.75,  2.00)  data  miles  with  correspond¬ 
ing  velocity  components  (0.50,  2.875,  0.0)  in  units  of  data  miles  per  second.  Assume  that 
the  track  is  an  air  track  that  is  maneuvering,  and  that  the  track  quality  is  90  (decimal).  Also 
assume  that  the  track  is  reported  by  Sensor.B  at  a  clock  time  of  496  (decimal)  milliseconds. 
In  this  case,  the  actual  bit  stream  for  the  track  update  message  (in  hex)  would  appear  as 

0C8200A5324021700200100058000000405A0002000001F0 

The  total  length  of  the  track  update  message,  illustrated  above,  is  24  bytes.  Of  these,  only 
12  bits  are  not  used  in  the  representation  of  the  message. 
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3.  ASN.1  Basic  Encoding  Ruies 

3.1 .  Overview 

The  Abstract  Syntax  Notation  One  (ASN.1)  is  an  international  standard  for  the  specification 
and  representation  of  data.  It  is  well  known  and  used  in  other  international  standards.  Be¬ 
cause  it  is  an  international  standard,  it  is  a  natural  candidate  to  consider  for  data  specifi¬ 
cation  and  representation. 

An  ASN.1  specification  is  encapsulated  within  a  module.  A  module  can  Include  an  inport 
and  export  list  to  indicate  references  to  types  and  objects  declared  In  other  modules.  A  mod¬ 
ule  can  also  contain  definitions  that  can  represent  type  declarations  or  value  declarations. 
Finally,  an  ASN.1  module  can  contain  macro  declarations.  A  macro  declaration  can  be  used 
to  change  the  syntax  of  the  ASN.1  specification  language  when  an  ASN.1  specification  is 
being  compiled.  Although  unique  in  concept,  use  of  the  macro  facility  complicates  the  de¬ 
velopment  of  a  compiler  for  ASN.1  specifications.^ 

It  is  important  to  note  that  ASN.1  can  be  used  to  produce  very  general  specifications  and 
has  significant  expressive  capabilities.  In  this  report  we  will  be  concerned  with  only  a  subset 
of  the  ASN.1  specification  to  illustrate  its  applicability  to  the  real-time  domain,  which  is 
predominated  by  certain  data  types.  We  will  also  be  concerned  with  the  ASN.1  specification 
mechanism  only  to  the  extent  that  it  is  used  in  the  example  of  the  track  update  message. 
However,  the  ASN.1  specification  grammar  appears  in  Appendix  A  in  a  BNF  form. 


3.2.  Encoding  Scheme 

The  mechanism  by  which  data  is  represented  in  ASN.1  is  defined  as  a  set  of  basic  encoding 
njles  (BER),  specified  in  ISO/IEC  8825  [3].  These  rules  are  used  by  the  presentation  service 
pr'^vider  in  the  ISO  model.  Each  encoding  consists  of  the  following  three  items: 

1 .  identifier 

2.  length 

3.  Value 


^Rose  discussss  some  issues  regarding  the  mac.o  facility  [8].  This  reference  also  contains  a  critica]  examina¬ 
tion  of  ASN.1  in  general. 
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The  structure  of  an  encoding  is  presented  in  Figure  3*1 .  The  identifier  is  encoded  in  one 
octet  and  contains  the  foiiowing  fields: 

•  Class:  ASN.1  specifies  4  classes  of  encodings,  namely,  universal,  application- 
wide.  context-specific,  and  private,  which  are  encoded  in  the  first  2  bits  of  the 
identifier  using  the  values  0. 1 . 2.  and  3.  respectively.  A  universal  tag  is  used  to 
define  an  application-independent  data  type  that  is  of  general  use.  An 
application-wide  tag  is  used  to  define  an  application-oriented  data  type  that 
needs  to  be  distinguished  from  other  data  types.  A  context-specific  tag  is  used 
to  distinguish  among  alternatives  of  a  data  type,  such  as  members  of  a  set. 
Finally,  a  private  tag  is  used  to  define  data  types  that  are  used  in  a  limited 
domain. 

•  Form:  An  encoding  may  be  primitive  or  constructed,  depending  upon  the  data 
type.  For  example,  an  integer  is  encoded  as  a  primitive,  while  a  sequence  is 
encoded  in  a  constructed  form,  meaning  that  it  is  an  encapsulation  of  encod¬ 
ings.  The  encoding  method,  denoted  by  PC  in  Figure  3-1 ,  is  contained  in  one 
bit.  with  primitive  and  constructed  being  denoted  by  0  and  1  respectively. 

•  Tag:  The  tag  number  is  an  indication  of  the  data  type. 


Length 


...  Contents  ... 


Figure  3>1 :  Structure  of  an  ASN.1  Encoding 

The  length  is  contained  in  one  or  more  octets  and  denotes  the  number  of  octets  of  data 
present.  In  this  report  we  will  be  concerned  with  a  definite  form  of  length  which  is  one  that  is 
encoded  in  a  single  octet.  Other  forms  are  possible,  including  a  specification  of  an  indefinite 
form  where  the  length  of  the  data  is  determined  from  special  characters  contained  in  the 
data. 

The  value  of  an  encoding,  referred  to  as  the  contents,  contains  the  actual  data.  For 
certain  encodings,  there  may  not  be  any  values  present. 


3.3.  Components 

In  discussing  the  encodings  used  in  ASN.1 .  we  will  partition  the  ASN.1  data  types  into  com¬ 
ponents  consisting  of  (i)  primitive,  (ii)  constructed,  and  (iii)  dual  encodings.  These  are  dis¬ 
cussed  in  the  following  subsections. 
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3.3.1.  Primitive  Components 

A  primitive  component  is  one  that  is  encoded  as  a  single  entity.  The  integer,  Boolean, 
enumerated,  real,  and  null  are  included  within  this  class  and  are  discussed  below. 

3.3.1 .1.  integer 

An  integer  is  encoded  using  one  or  more  contents  bytes,  represented  as  a  two’s  comple¬ 
ment  binary  number.  The  encoding  is  such  that  the  contents  field  is  encoded  using  the  smal¬ 
lest  number  of  bytes.  The  universal  class  tag  for  an  integer  is  2. 

3.3.1 .2.  Booiean 

The  contents  field  of  a  Boolean  Is  encoded  using  one  byte.  The  value  FALSE  is  encoded  as 
zero,  and  TRUE  is  encoded  as  any  non-zero  value.  The  universal  class  for  a  Boolean  is 
1. 


3.3.1 .3.  Enumerated 

The  encoding  of  an  enumerated  type  is  the  same  as  that  of  the  integer  value  that  is  associ¬ 
ated  with  the  type.  The  universal  class  tag  for  an  enumerated  type  is  10. 

3.3.1 .4.  Real 

The  representation  of  a  real  value  may  Include  one  of  the  following:  (i)  the  value  zero,  (ii)  a 
binary  representation  of  a  real  value,  (iii)  a  character-based  decimal  representation  of  a  real 
number,  and  (iv)  certain  special  real  values.  The  universal  class  tag  for  a  real  type  is  9. 

The  value  0.0  is  encoded  by  setting  the  length  field  to  0.  That  is.  there  are  no  contents 
octets. 

If  bit  8  of  the  first  contents  byte  has  the  vsdue  1,  the  encoding  is  that  of  a  binary  represen¬ 
tation  of  a  real  number.  A  real  value  is  represented  in  the  following  form: 

SN2^B^ 

where  S  is  the  sign,  N  is  a  number  related  to  the  mantissa,  F  is  a  scale  factor  in  the  range 
[0. 4),  B  is  the  base,  and  E  is  the  exponent.  The  elements  of  the  encoding  are  based  on  the 
following: 

•  The  sign  is  contained  in  bit  7  of  the  first  contents  octet.  The  values  positive  and 
negative  are  represented  by  0  and  1 .  respectively. 

•  The  base  is  contained  in  bits  6  and  5  of  the  first  contents  octet  and  can  have 
the  values  0, 1 ,  or  2,  denoting,  respectively,  base  2, 8,  or  16. 

•  The  scale  factor  F  is  contained  in  bits  4  and  3  of  the  first  contents  octet  arKf 
directly  represent  a  value  I  the  range  [0. 4). 

•  The  format  of  the  exponent  is  indicated  in  bits  2  and  1  of  the  first  contents  octet 
and  has  the  following  interpretation: 

•  If  bits  2  and  1  have  the  value  00,  then  the  second  contents  octet  contains 
the  value  of  the  exponent. 

•  If  bits  2  and  1  have  the  value  01,  then  the  second  and  third  contents  octet 
contains  the  value  of  the  exponent. 
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•  If  bits  2  and  1  have  the  value  10.  then  the  second,  ttiird  and  fourth  con¬ 
tents  octets  contains  the  value  of  the  exponent 

•  If  bits  2  and  1  have  the  value  11.  then  the  second  octet  specifies  the 
number  of  octets  that  are  used  for  the  exponent  The  actual  value  of  the 
exponent  appears  in  the  following  number  of  octets. 

•  in  all  cases,  the  exponent  is  stored  as  a  two’s  comp)lement  binary  num¬ 
ber. 

•  The  value  of  N  is  encoded  as  a  binary  integer  In  the  remaining  contents  octets. 

If  bits  8  and  7  of  the  first  contents  byte  have  the  value  "OO."  the  encoding  is  that  of  a 
character-based  decimal  encoding.  This  is  similar  to  an  ASCII  representation  with  the  inter¬ 
pretation  of  the  remainder  of  the  encoding  being  specified  by  certain  intemationai  standards. 

If  bits  8  and  7  of  the  first  contents  byte  contains  the  value  "01 .”  a  special  real  value  is 
present.  The  two  values  defined  by  the  standard  are  plus  and  minus  infinity,  encoded  as  the 
bitstrings  01000000  and  01000001  respectively.  When  a  special  real  value  is  present,  there 
will  be  only  one  contents  byte.  Other  possible  encodings  are  reserved  for  future  use. 

It  may  help  to  clarify  matters  to  consider  an  example  of  an  encoding  of  a  real  type.  Con¬ 
sider.  for  example,  the  interpretation  of  the  hex  string  "090680E60ADF0A8B.*  The  inter¬ 
pretation  of  this  is  illustrated  in  Figure  3-2. 


XS  B  F  Y 


Rgure  3-2:  Example  of  a  Real  Type  in  ASN.1 

The  following  are  to  be  noted  about  the  interpretation: 

•  The  first  byte  contains  the  tag  T.  which  in  this  case  is  9.  representing  a  real 
type. 

•  The  second  byte  contains  the  length  L 

•  The  third  byte  contains  the  first  byte  of  the  contents  and  is  Interpreted  as  fol¬ 
lows: 

•  The  first  bit  (bit  8)  indicates  that  ttie  real  value  is  encoded  in  binary. 

•  Bit  7  indicates  that  the  sign  of  the  number  is  positive. 

•  Bits  6  and  5  represent  the  base  B.  The  value  of  zero  irtdicates  base  2. 

•  Bits  4  and  3  contain  the  value  of  the  scale  factor  F.  which  is  0. 


12 


CMU^EI-93-TR-10 


•  Bits  2  and  1  indicate  that  the  exponent  occupies  one  byte  of  storage. 

•  The  value  contained  in  byte  4  denotes  the  exponent  E;  in  this  case,  the  value  is 
-26. 

•  The  last  four  t^es  of  the  encoding  contain  the  value  of  N. 

When  the  value  of  N  is  converted  to  decimal  and  multiplied  by  the  factor  of  2'^,  the  result  is 
the  value  of  e.  the  base  of  natural  logarithms. 

It  is  important  to  note  that  there  are  multiple  valid  BER  encodings  for  a  real  number.  For 
example,  the  value  of  e  as  discussed  above  could  also  be  represented  by  the  hex  string 
"090681 7FE9ADF84D."  In  this  case,  the  header  indicates  that  the  exponent  is  represented 
in  two  octets,  with  the  remaining  three  octets  representing  the  mantissa. 

The  encoding  specified  for  a  real  type  by  ASN.1  does  not  relate  to  any  specific  hardware, 
nor  is  the  encoding  based  on  any  other  standard  such  as  the  IEEE  Standard  for  floating 
point  numbers  [1].  However,  it  is  stated  in  iSO/lEC  8825  [3]  that  the  ASN.1  representation 
was  chosen  to  be  easily  converted  to  and  from  other  formats.  See  Appendix  C. 

3.3.1 .5.  Null 

An  object  of  the  null  type  is  encoded  such  that  the  length  flekf  is  0  and  there  is  no  contents 
field  present.  The  universal  class  ts^  for  a  null  type  is  5. 

3.3.2.  Constructed  Components 

A  constructed  encoding  is  one  in  which  the  encoding  comprises  one  or  more  data  values. 
Such  encodings  are  used  for  structures  and  records,  for  example. 

3.3.2.I.  Sequence 

ASN.1  provides  for  specifying  a  sequence  or  sequence-of  data  types.  The  encoding  encap¬ 
sulates  the  encodings  of  ^e  component  data  types.  In  the  case  of  a  sequence,  the  encod¬ 
ing  must  appear  in  the  same  order  as  defined  in  the  specification,  but  the  sequence  can 
consist  of  many  different  data  types.  For  a  sequence-of,  tiie  order  must  also  be  preserved, 
but  all  components  of  a  sequence-of  must  be  of  the  same  data  type.  The  universal  class 
tag  for  a  sequence  or  sequence-of  is  16. 


3.3.2.2.  Set 

Similar  to  a  sequence.  ASN.1  provides  for  a  set  and  set-of  that  represent  an  unordered  col¬ 
lection  of  objects.  The  encoding  for  the  elements  of  the  set  can  be  chosen  at  will  by  the 
encoder.  Also,  as  with  the  sequence  and  sequence-of,  a  set  can  consist  of  components  of 
many  different  types,  while  a  set-of  consists  only  of  components  of  the  same  type.  The 
universal  class  tag  for  a  set  or  set-of  will  be  17. 
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3.3.3.  Dual  Encoded  Types 

Certain  of  the  ASN.1  types  can  be  encoded  using  either  a  primitive  or  constructed  form. 
These  are  discussed  beiow. 

3.3.3.1.  Bit  String 

A  bit  string  is  encoded  as  a  sequence  of  zero.  one.  or  more  octets  of  data.  The  universal 
class  tag  for  a  bit  string  type  is  3. 

3.3.3.2.  Octet  String 

An  octet  string  represents  zero.  one.  or  mode  octets  of  data.  The  universal  class  tag  for  an 
octet  string  type  is  4. 

3.3.4.  Additional  Points 

The  preceding  has  covered  the  basic  components  of  ASN.1  types  and  associated  basic  en¬ 
coding  rules.  It  is  to  be  noted  that  ASN.1  includes  additional  items  that  may  be  useful  to  a 
designer.  For  example,  one  can  specify  objects  of  generalized  and  universal  time  (although 
they  are  encoded  as  character  strings).  ASN.1  also  includes  subtypes  and  a  macro  facility 
that  is  quite  powerful;  for  example,  one  can  extend  the  syntax  of  ASN.1 .  For  further  discus¬ 
sion  of  the  above  items  the  reader  is  referred  to  ISO/IEC  8824  [2],  ISO/IEC  8825  [3],  and 
Steedman's  ASM.  1:  The  Tutorial  and  Reference  [9]. 


3.4.  Example 

The  development  of  the  ASN.1  specification  is  fairiy  straightforward.  Thus,  in  reference  to 

Figure  2-3,  we  note  the  following: 

•  The  track  update  message  is  encapsulated  in  a  module  called  track  messages. 

The  use  of  a  module  specification  in  ASN.1  allows  common  data  types  to  be 
grouped  together.  In  addition,  modules  can  export,  import,  and  reference  speci¬ 
fications  defined  in  other  modules;  this  is  an  attractive  feature  of  ASN.1 . 

•  The  message  itself  is  represented  as  a  sequence.  This  implies  that  the  encod¬ 
ing  of  the  message  will  be  the  ordered  encodings  of  the  message  components. 

•  The  number  of  words,  message  type,  track  index,  track  quality,  and  the  value  of 
the  clock  are  encoded  as  integers. 

•  The  track  category  and  maneuver  indicator  are  encoded  as  Boolean  types. 

•  The  sensor  type  is  specified  as  an  enumerated  type  with  the  enumerated 
values  appearing  in  the  specification. 

•  The  position  and  velodfy  data  is  represented  as  a  string  of  octets.  This  choice 
is  made  because  ASN.1  does  not  provide  for  the  specification  of  a  fixed-point 
type.  This  implies  that  a  tool  to  decode  the  message  would  have  to  perform 
special  processing  for  tiie  position  and  velocity  data. 

The  ASN.1  specification  is  presented  in  Figure  3-3. 


14 


CMU/SEI-93-TR-10 


SKQUBMCB  { 

MUMBBRJfOBDS 

MBSSAGBjrXPE 

TRACK_1NDEX 

POSITION_AND_V*LOCITY 

TRACK_CATEGOR3r 

iaMDSVER_IMDICATOR 

TRACKjQl^lTY 

SENSOR 


CLOCK 


IMTECOR  (1  .  .  32767) , 

INTEGER  (1  . .  32767) , 

INTEGER  (1  . .  511)  , 

OCTET  STRING  (SIZE  (12)), 
BOOLEAN, 

BOOLEAN, 

INTEGER  (0  . .  100) , 
ENUMERATED 

(SENSORJl  «  1,  SSNSOR_B 
SENSORjC  «  4,  SENSORJD 
SENSORJB  >16,  SENSOR_r 
SENSORJS  >  64,  SENSOR_H 
SENSOR_I  >  256,  SBNSOR_J 
INTEGER  ~ 


DATA 


2, 

8, 

32, 
128, 
512  ), 


Figure  3-3:  ASN.1  Specification  of  Track  Update  Message 


In  terms  of  the  values  specified  in  Section  2.3.2,  the  ASN.1  encoding  of  the  track  update 
message  would  appear  as  follows: 

30lF020C028202A5041032402170020100058000000001000irr 

025A0A020201F0 


The  total  length  of  the  message  in  the  ASN.1  BER  encoding  is  33  bytes.  The  representation 
discussed  in  Section  2.3  required  a  total  of  24  bytes. 
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4.  External  Data  Representation 


4.1.  Overview 

The  external  data  representation  (XDR)  is  a  standard  developed  by  Sun  Microsystems  for 
the  description  of  data  [4].  This  starKlard  is  used  in  the  definition  of  Sun  RPC  [5]  as  weii  as 
the  Versatile  Message  Transaction  Protocol  (VMTP),  defined  by  Cheriton  [6]. 

Some  of  the  characteristics  of  XDR  include  the  following: 

•  A  data  representation  carries  no  information  about  the  data  type.  It  is  argued 
that  receivers  know  what  data  types  are  expected  and  that  induding  such  infor¬ 
mation  is  not  of  particular  use. 

•  The  data  encoding  is  assumed  to  be  a  big  endian  format.  This  format  is  used 
on  IBM  and  Motorola  machines,  but  not.  for  example,  by  the  VAX  family,  which 
uses  little  endian. 

•  XDR  assumes  that  all  data  are  encoded  as  a  multiple  of  four  bytes.  This 
means,  for  example,  that  a  Boolean  object  will  be  represented  in  terms  of  32 
bits. 

Our  interest  is  more  in  the  data  representation  aspect  of  XDR.  Appendix  B  contains  a  BNF 
specification  of  the  language  associated  with  XDR.  In  the  following  subsections,  we  present 
the  components  of  the  XDR  representation. 


4.2.  Components 

4.2.1.  Integer 

An  integer  is  represented  as  a  32-bit  unit  in  the  range  [-2147483648.  2147483647].  The 
integer  is  represented  in  two's  complement  notation.  XDR  also  supports  an  unsigned  in¬ 
teger  with  values  in  the  range  [0. 4294967295].  In  the  latter  case,  the  high-order  bit  is  inter¬ 
preted  as  data,  not  a  sign  bit 

XDR  also  supports  a  hyper  integer  and  an  unsigned  hyper  integer  type.  These  are  exten¬ 
sions  of  the  integer  and  unsigned  integer  types,  but  they  occupy  eight  bytes  as  opposed  to 
four. 

4.2.2.  Boolean 

A  Boolean  is  represented  with  the  value  TRUE  as  1.  and  FALSE  is  represented  as  0.  in 
each  case,  the  object  assumes  4  bytes. 
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4.2.3.  Enumerated 

XDR  supports  enumerated  types;  an  example  of  the  syntax  is  as  follows: 

•nun  {  RED  *  2,  BLUE  *  12,  GREEN  «  15  )  colors; 

The  representation  of  an  enumerated  type  is  identical  to  that  of  an  integer  type. 

4.2.4.  Floating  Point 

The  representation  of  a  floating  point  type  is  that  specified  by  IEEE  745-1985  [1]  for  normal¬ 
ized  floating  point  numbers.  The  representation  includes  the  sign,  exponent,  and  fraction, 
described  as  follows: 

•  The  sign  of  the  number  is  represented  as  one  bit,  with  the  values  0  and  1 
denoting  positive  and  negative  numbers,  respectively. 

•  The  exponent  is  represented  in  base  2  with  a  bias  of  127.  A  total  of  8  bits  are 
used  to  store  the  exponent. 

•  The  fraction  is  represented  in  base  2  and  is  stored  in  23  bits. 

The  result  of  the  above  is  that  a  (single  precision)  floating  point  number  is  described  as: 

*  2**  (Exponent  -  127)  *  1. Fraction 

The  IEEE  standard  also  describes  special  floating  point  types  that  may  be  included  as  part 
of  an  XDR  specification.  Examples  of  this  include  signed  zero  and  signed  infinity  (to  repre¬ 
sent  overflow).  XDR  also  provides  for  a  specification  of  a  double  precision  floating  point 
type  that  is  an  extension  of  the  single  precision  floating  point  type,  described  above.  The 
double  precision  floating  point  is  also  represented  according  to  the  IEEE  standard  [1].^ 

4.2.5.  Opaque  Data 

Opaque  data  is  defined  in  XDR  as  uninterpreted  data  that  is  passed  between  machines.  An 
XDR  specification  may  describe  either  fixed-length  or  variable-length  opaque  data.  In  each 
case,  the  data  is  represented  as  a  multiple  of  four  bytes  with  additional  zero-byte  padding  as 
needed. 

An  opaque  data  specification  can  be  used  to  describe  data  that  will  be  processed  by  the 
data  rather  than  the  presentation  senrices.  For  example,  a  file  can  be  encoded  as  opaque 
data  indicating  that  no  operation  is  performed  on  the  data  by  an  automatically  generated 
tool.  In  this  sense,  opaque  data  can  be  used  to  hide  the  internals  of  the  data  representation. 


^The  IEEE  floating  point  standard  [1],  also  specifies  extended  floating  point  types.  These  are  not  included  in 
the  XDR  specification. 
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4.2.6.  String 

A  string  is  represented  in  terms  of  unsigned  integers  and  assumes  the  ASCii  character  set. 
The  first  4  bytes  of  the  representation  define  the  length  of  the  string.  A  length  declaration 
may  be  omitted,  in  which  case  the  maximum  length  of  2**32  -1  bytes  is  assumed.  The  data 
follows  the  length  specification  and  must  be  a  multiple  of  4  bytes. 

4.2.7.  Arrays 

A  group  of  homogeneous  elements  can  be  encoded  in  XDR  as  an  array.  The  specification 
provides  for  both  fixed-length  and  variable-length  encodings.  In  the  latter  case,  the  length  is 
included  as  the  first  four  bytes  of  the  representation,  encoded  as  an  unsigned  integer. 

4.2.8.  Structure 

A  structure  declaration  in  XDR  is  based  on  that  defined  in  the  C  programming  language  and 
has  the  syntax; 

struct  { 

conponent-l ; 
coaponent-2 ; 

coxnponent  -n ; 

}  structure-name; 

Each  component  of  the  structure  is  encoded  in  the  order  in  which  it  is  declared.  The  size  of 
each  component  must  be  a  multiple  of  four  bytes,  although  each  component  may  have  dif¬ 
ferent  sizes. 

4.2.9.  Discriminated  Union 

XDR  permits  a  specification  of  a  discriminated  type,  which  is  called  a  discriminated  union. 
An  example  of  a  discriminated  union  appears  below; 

enum  {  XTP  »  1,  OSI-COKNECTIONLESS  s  2  ) 
protocol; 

union  switch  (PROTOCOL) 
case  XTP: 

/*  XTP  protocol  data  specification  */ 
case  OSI -CONNECTIONLESS: 

/*  Connectionless  protocol  data  specification  */ 

}  ; 


The  enumerated  type  specifies  two  different  protocols,  namely  XTP  and  OSI  Connection¬ 
less,  along  with  the  particular  values  of  each  instance.  Following  this  are  the  specifications 
for  each  particular  protocol  instance. 

The  representation  of  a  discriminated  union  consists  of  two  parts.  First,  the  discriminant  is 
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encoded  in  four  bytes.  The  second  part  of  the  encoding  is  the  data  for  the  specified  dis¬ 
criminant  value. 

4.2.10.  Void 

A  void  Is  a  zero-byte  quantity  that  can  be  used  in  XDR  specifications.  A  void  specification  is 
useful  for  operations  that  do  not  require  any  data  as  input  or  output,  for  example.  It  can  also 
be  used  to  specify  a  null  branch  of  a  discriminated  union. 

4.2.11.  Additional  Points 

The  XDR  specification  also  allows  for  the  specification  of  constants,  optional  data,  and  iden¬ 
tifiers  used  for  decl2iring  other  data.  These  are  discussed  in  [4]. 


4.3.  Example 

We  now  consider  the  XDR  specification  for  the  track  update  message,  introduced  in  Section 

2.3.  The  message  will  be  represented  as  a  structure  whose  components  are  the  elements 
in  the  track  update  message.  The  XDR  specification  is  presented  in  Figure  4-1 . 


struct  { 

int 

NUMBER  WORDS; 

int 

MESSAGE  TYPE; 

int 

TRACK_ZNDEX; 

opsqu* 

POSITIONJMn)_VBLOCiaTJ>ATA  [12]  ; 

bool 

TRACKjCAXEGORX; 

bool 

MANOEVER  INDICATOR; 

int 

TRACKjQOALITY; 

enum 

{SENSOR_A  «  1,  SENSOR_B  >  2,  SENSORJC  -  4, 

SENSOR_D  B  8,  SENSOrTe  »  16,  SENSOR_F  ^  32, 
SENSORJS  «  64,  SENSOR  H  s  128,  SENSOR  I  >  256, 
SENSOR  J  «  512  )  SENSOR; 

unsignad  int  CLOCK; 

> 

TRACK  UPDATE  MESSAGE; 

Figure  4-1 :  XDR  Specification  of  Track  Update  Message 

The  development  of  the  XDR  specification  is  fairiy  straightforward,  for  example: 

•  The  number  of  words  in  the  message,  message  type,  track  index,  and  track 
quality  are  represented  as  integers. 

•  The  track  category  and  maneuver  indication  are  represented  as  Boolean. 

•  The  sensor  type  is  represented  as  an  enumerated  type  with  each  sensor  identi¬ 
fied. 

•  The  value  of  the  clock  is  represented  as  an  unsigned  integer. 

There  is,  however,  one  Issue  in  the  use  of  XDR  to  specify  the  track  update  message.  Sev¬ 
eral  of  the  quantities  in  the  message  are  defined  as  fixed-point  types,  although  XDR  does 
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not  provide  such  a  specification.  We  could  have  represented  these  as  some  other  type, 
such  as  an  integer,  but  instead,  chose  to  represent  the  fixed-point  types  in  terms  of  opaque 
data.  Thus,  as  shown  in  Figure  4-1 ,  the  position  and  velocity  data  is  simply  declared  as  an 
array  of  length  12  of  opaque  data.  Recall,  the  use  of  opaque  data  hides  tiie  internal  repre¬ 
sentation  of  the  data.  In  the  present  case,  it  would  not  be  possible,  for  example,  for  an 
automated  tool  to  encode  or  decode  opaque  data.^ 

In  terms  of  the  parameters  given  in  Section  2.3.2,  the  XDR-encoded  track  update  message 
would  appear  as  follows: 

0000000C00000082000000A5324021700200100058000000 

0000000000000001000000AA00000002000001FO 

The  total  length  of  the  message,  in  the  XDR  form,  is  seen  to  be  44  bytes.  Recall  that  the 
storage  required  for  the  track  update  message,  discussed  in  Section  2.3,  only  required  a 
total  of  24  bytes. 


^Strictly  speaking,  one  cnuld  modify  a  tool  to  handle  the  fixed-point  types, 
extending  the  definition  of  the  XDR  specification. 


However,  this  is  tantamount  to 
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5.  Comparison  of  Approaches 

5.1.  Qualitative 

A  qualitative  comparison  of  ASN.1  and  XDR  can  be  made  based  on  the  preceding  as  well 
as  the  standards  definitions  contained  in  ISO/IEC  8824  [2],  ISO/IEC  8825  [3],  and  the  XDR 
Standard  [4].  The  following  points  are  relevant: 

•  The  specification  of  ASN.1  is  more  expressive  than  that  of  XDR.  This  is 
achieved,  in  part  through  the  use  of  modules,  which  allows  for  the  application 
or  modem  software  engineering  practices.  In  addition,  the  presence  of  subtyp¬ 
ing  multiple  class  tags  also  provides  general  capabilities  to  an  application. 

Also,  the  macro  capability  of  ASN.1  permits  one  to  generr  lew  specifications; 
in  fact,  one  can  redefine  the  syntax  of  ASN.1  through  this  Capability. 

•  The  data  specification  and  representation  capabilities  of  ASN.1  are  more  gen¬ 
eral  than  that  of  the  XDR  standard.  The  encoding  of  data  in  minimal  length  for¬ 
mats,  such  as  integer  and  Boolean  types,  conserves  buffer  space  and  may 
have  implications  for  network  bandwidth  allocation.  It  was  noted  in  the  text  that 
the  real  type  declared  by  ASN.1  is  not  suited  to  any  particular  hardware  repre¬ 
sentation,  and  this  further  illustrates  the  generality  of  the  ASN.1  approach. 

Of  course,  an  application  could  pay  a  significant  price  for  the  generality  contained  in  the 
ASN.1  specification  and  encoding  standards.  XDR  maps  all  data  onto  32-bit  aligned  bound¬ 
aries,  and  employs  current  standards  for  floating  point  representation,  such  as  the  lEE  float¬ 
ing  point  standard  [1].  Clearly,  XDR  Is  oriented  toward  systems  in  widespread  use  today  and 
seeks  to  achieve  an  efficient  data  representation. 

Many  factors  are  involved  in  a  decision  concerning  the  use  of  a  data  specification  and  repre¬ 
sentation  standard.  One  concern  in  the  real-time  domain,  where  end-to-end  deadlines  are 
important,  is  that  of  performance.  In  the  following  section,  we  present  some  discussion  of 
quantitative  measures  to  compare  ASN.1  and  XDR. 


5.2.  Quantitative 

It  is  desirable  to  have  quantitiitive  metrics  to  compare  ASN.1  and  XDR.  Such  metrics  can 
help  application  designers  in  the  selection  of  a  data  specification  and  representation  stan¬ 
dard.  In  the  following  two  sections  we  present  two  simple  metrics  regarding  buffer  sizes  and 
processing  times. 

5.2.1.  Buffer  Sizes 

Given  a  set  of  data  to  be  encoded  according  to  some  specification,  one  concern  is  the 
amount  of  storage  required  for  the  resulting  data.  The  storage  required  is  important  be¬ 
cause  it  contributes  to  the  bandwidth  required  to  transmit  the  data.  In  addition,  a  greater 
amount  of  storage  requires  more  data  movement  among  components  (for  example,  back¬ 
planes  and  protocol  chip  sets). 
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One  applicable  metric  is  the  ratio  of  buffer  sizes  for  two  representations.  Let  S(enooding|) 
denote  the  required  buffer  size  to  encode  data  according  to  standard  i.  We  then  consider 
the  ratio: 

SiencodingD 

Siencodingp 

In  relation  to  the  example  considered  in  the  text  for  the  track  update  message,  let  S(raw) 
denote  the  size  of  the  data  as  specified  in  Figure  2-3.  Then,  we  have: 

S(ASN1.  raw) »  33/24  »  1.4. 

S(XDR.  raw) »  44/24^1.8. 


and 


S(XDR.  ASN1) »  44/33  »  1.3. 

In  the  case  of  the  track  update  message,  the  use  of  the  XDR  representation  nearly  doubles 
the  size  of  the  buffer  required  to  store  the  message. 


5.2.2.  Processing  Times 

A  second  appropriate  metric  concerns  the  amount  of  time  to  encode  and  decode  data.  Let 
T(i;  k.  X)  denote  the  amount  of  time  to  perform  operation  X  (encode  or  decode)  on  an  object 
of  type  k  according  to  data  representation  standard  i.  We  then  define 


71(1,;;  4,  X)  = 


m  k,X) 
T(j;k,X) 


to  be  the  ratio  of  times  to  perform  operation  X  on  an  object  of  type  k  for  standards  i  and  j. 


It  is  not  our  intent  here  to  perform  a  detailed  investigation  of  T(i,  j;  k.  X)  because  such  results 
are  influenced  by: 

•  Design  method  (automated  or  hand-coded,  for  example). 

•  Implementation  language. 

•  Target  machine  (underlying  instruction  set  architecture). 

To  illustrate  an  application  of  the  encode  times,  consider  the  case  of  an  integer  such  that  its 
value  can  be  represented  in  32  bits.  An  estimate  of  T,  expressed  in  terms  of  number  of 
machine  instructions,  would  give 


T(XDR;  integer;  X)  =  2. 


in  other  words,  a  4-byte  integer  could  be  encoded  or  decoded  in  two  instructions.  This  es¬ 
timate  assumes  one  instruction  to  fix  a  pointer  at  the  address  and  the  second  instruction  to 
move  the  32  data  bits.  Recall  that  the  XDR  specification  requires  boundary  alignment  of  4 
bytes  on  each  data  type. 
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A  corresponding  estimate  for  the  case  of  ASN.1  would  be  roughly 
T(ASN.1:  Integer;  X)- 7. 

where  the  majority  of  the  instructions  are  used  to  extract  (and  verify)  tag  and  length  infor¬ 
mation.  The  preceding  indicates  that  decoding  a  32-bit  integer  requires  about  3  times  as 
many  instructions  in  ASN.1  than  in  XDR.  In  the  case  of  a  floating  point  value  exchanged 
among  machines  that  conform  to  the  XDR  standard  (that  is.  that  employ  the  IEEE  floating 
point  standard  representation  [1]).  in  XDR  tiie  data  could  be  encoded  in  2  instructions.  An 
estimate  for  ASN.1/BER  encode  and  decode  routines  appears  in  Appendix  C.  There,  it  is 
illustrated  that  the  encode  and  decode  operations,  using  ASN.1  BER.  are  considerably  more 
expensive  than  when  done  in  XDR. 

The  inclusion  of  tag  information  in  the  ASN.1  encoding  must  be  accounted  for  in  any  perfor¬ 
mance  metric  to  encode  or  decode  data  of  a  particular  type.  To  some  applications,  this 
could  be  viewed  as  unnecessary  overhead. 

5.2.3.  Space  and  Time  Tradeoffs 

It  is  possible  to  combine  the  buffer  size  and  processing  time  metrics,  resulting  in  a 
composite  metric.  Such  a  metric  would  convey,  in  a  simple  manner,  the  two  metrics  intro¬ 
duced  above.  To  this  end.  define 


S’  =  S(l.j). 


and 


T’  =  T(I.J;k.X). 

The  composite  metric  is  obtained  by  displaying  data  in  the  S'-T  plane.  An  example  of  this  is 
presented  in  Figure  5-1  where  i  and  j  correspond  to  ASN.1  and  XDR.  respectively.  The 
point  labeled  x  in  this  figure  represents  the  values  of  S'  and  T  for  a  32-bit  integer.  In  this 
case.  ASN.1  requires  about  0.75  times  the  buffer  space  of  XDR.  However,  as  noted  above. 
ASN.1  requires  about  3.5  times  the  amount  of  assembler  instructions  to  decode  the  data. 
The  shaded  area  in  Figure  5-1  is  that  domain  in  the  S’-T  plane  for  which  the  representation 
specified  by  standard  i  is  more  efficient,  in  space  and  time,  than  that  specified  by  standard  j. 

We  are  unaware  of  any  detailed  metrics  for  comparing  ASN.1  and  XDR,  nor  are  we  aware 
of  any  type  of  benchmark  suite  that  would  seek  to  compare  these  standards.  We  believe 
that  the  existence  of  such  work  would  help  to  establish  quantitative  results  that  application 
systems  need  in  order  to  complete  a  detailed  performance  estimate  of  the  impact  of  using 
either  of  the  standards  discussed  here.  A  similar  approach  to  that  outlined  above  is  easily 
seen  to  apply  to  other  data  representation  standards. 
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5.3.  Issues 

5.3.1.  Typing  Considerations 

A  major  difference  betM^een  ASN.1  and  XDR  data  representations  is  that  the  former  carries 
type  information  whiie  the  iatter  does  not  The  utiiity  of  type  information  is  an  issue.  For 
exampie.  many  systems  are  expecting  data  of  a  pr^efined  type  and  to  encode  the  type 
information  requires  additionai  storage  as  well  as  processing  time. 

Neither  XDR  nor  ASN.1  inciude  any  provision  for  fixedpoint  types.  This  was  noted  in  the 
exampies  considered,  where  it  was  necessary  to  encode  fixed-point  data  in  some  other 
form,  in  the  case  of  the  XDR  specification  of  the  Track  Update  Message,  for  exampie,  the 
position  and  veiodty  data  were  encoded  as  opaque  data.  The  failure  of  a  specification  to 
support  a  particular  type  has  implications  for  the  ability  to  automate  the  processing  of  appli¬ 
cation  data. 
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5.3.2.  Byte  Ordering  and  Alignment 

The  XDR  specification  requires  a  big  endian  byte  ordering.  This  form  is  used  in  IBM  and 
Motorola  class  machines.  However,  the  VAX  family  uses  a  little  endian  byte  ordering. 

The  criteria  for  byte  alignment  may  be  important  in  system  considerations.  The  XDR  specifi¬ 
cation  is  based  on  a  four-byte  wide  representation,  while  the  ASN.1  specification  is  of  vari¬ 
able  length. 

5.3.3.  Use  of  Other  Representations 

This  report  has  considered  the  use  of  the  ASN.1  Specification  and  basic  encoding  rules  and 
the  external  data  representation.  Both  of  these  are  well  known  and  widely  used  in  distributed 
systems.  There  are  other  systems  that  address  similar  issues  as  these  which  cteserve  con¬ 
sideration.  A  notable  case  in  point  is  the  interface  description  language  (iOL)  developed  by 
Nestor  et  al  [7].  Although  originally  intended  for  use  in  compiler  technology  (IDL  is  the  dls 
facto  intermediate  representation  for  Diana,  which  is  used  in  Ada  compiler  technology).  IDL 
applies  to  the  problems  considered  in  this  report,  in  fact.  IDL  provides  capabilities  not  found 
in  either  of  the  systems  considered. 

5.3.4.  Automated  Tools 

If  one  were  to  use  a  data  specification  and  representation  standard,  such  as  ASN.1 .  XDR.  or 
IDL,  it  would  clearly  be  advantageous  to  have  automated  tooling  to  support  encode  and 
decode  operations.  Such  a  tool  would  allow  a  designer  to  specify  the  data,  and  the  tool 
would  generate  the  encode  and/or  decode  routine.  There  are  such  tools  available  for  each 
of  the  above  three  specifications. 

5.3.5.  Revisions  to  ASN.1 

During  the  preparation  of  this  report,  we  became  aware  of  changes  that  are  being  proposed 
to  the  basic  encoding  rules  to  ASN.1.  ISO/IEC  8825  [3].  These  Include  the  following: 

•  A  set  of  packed  encoding  rules  (PER)  that  results  in  a  more  compressed  en¬ 
coding  than  ASN.1  basic  encoding  rules.  For  example  an  integer  in  the  range 
(100  ...  103)  can  be  encoded  in  the  PER  using  2  bits.  This  is  achieved  by  add¬ 
ing  an  offset  of  100  to  the  encoded  value,  thereby  requiring  less  storage  than 
that  for  a  basic  encoding. 

•  A  set  of  canonical  and  distinguishing  encoding  rules  that  are  based  on  the  basic 
encoding  rules.  These  encodings  would  require,  for  example,  that  a  Boolean 
be  encoded  as  1  if  the  value  were  TRUE  and  0  if  FALSE  (recall  the  BER  state 
that  a  Boolean  having  the  value  TRUE  can  be  encoded  as  any  non-zero  value). 

The  advantage  of  a  canonical  and  distinguished  encoding  is  that  it  standardizes 
the  encodings  of  certain  elements. 

•  There  is  also  some  possibility  that  a  set  of  light  weight  encoding  rules  (LWER) 
will  be  standardized.  These  are  intended  to  be  faster  to  encode  and  decode 
than  the  basic  encoding,  although  the  encodings  may  require  more  storage. 

It  is  our  understanding  that  the  first  two  encodings  listed  above  are  draft  international  stan¬ 
dards,  while  the  LWER  is  under  consideration. 
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6.  System  Design  Considerations 

Although  this  report  has  focused  on  the  data  representation  issues,  the  question  of  data 
representation  exists  in  a  larger  context.  In  particular,  the  use  of  data  representation  ser¬ 
vices  (such  as  encode  and  decode)  represent  a  part  of  the  execution  time  expended  in  sup¬ 
port  of  end-to-end  deadline  processing.  In  the  following,  we  examine  some  system  con¬ 
siderations  related  to  this  larger  context. 


6.1.  Analysis 

We  will  now  present  a  simple  analysis  of  tiie  contribution  to  the  end-to-end  completion  time 
in  the  case  of  heterogeneous  systems.  For  such  systems,  we  assume  that  a  data  represen¬ 
tation  scheme,  such  as  ASN.1  BER,  is  used,  in  the  case  of  a  peer-to-peer  communication, 
there  are  two  contributions  to  the  end-to-end  .completion  time  that  must  be  considered, 
namely 

•  The  time  for  the  sender  to  encode  the  data  before  message  transmission. 

•  The  time  for  the  receiver  to  decode  the  received  data. 

Consider  the  case  in  which  a  message  is  transmitted  at  a  periodic  rate  R  times  per  second. 
Assume  that  the  message  can  contain  nj  values  of  data  of  type  !.  For  example,  one  could 
delineate  the  set  whose  elements  represent  integer  types,  Boolean  types,  floating  point 
types,  etc.  To  account  for  the  encoding  and  decoding  times  we  define 

•  to  be  the  time  required  to  encode  a  data  type  i  on  processor  p. 

•  to  be  the  time  required  to  decode  a  data  type  i  on  processor  p. 

The  inclusion  of  the  subscript  p  in  the  above  is  to  distinguish  that  the  times  to  perform 
encode  and  decode  operations  are  processor-dependent.^ 

Based  on  the  above,  the  contribution  to  the  end-to-end  completion  time  T  is  given  by  the 
following  expression: 

1 

It  is  possible  to  extend  the  development  of  the  formalism  in  a  natural  manner.  For  example, 
it  can  be  developed  for  a  specific  message  type  or  be  extended  to  include  worst-case  times 
for  processing  messages  that  are  transmitted  in  a  multicast  manner.  We  will  not  explore 
further  development  of  the  formalism  here.  Rather,  our  intent  is  to  be  able  to  illustrate  the 
impact  of  encode  and  decode  operations  in  a  heterogeneous  context. 


^There  are  also  compiler  and  language  dependencies,  but  they  need  not  be  included  for  purposes  of  the 
current  discussion. 
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6.2.  Example 

We  now  consider  an  example  of  the  formalism  developed  above.  Consider  the  case  of  the 
track  update  message,  described  in  Section  2.3.  We  will  assume  as  part  of  the  transition  to 
an  open  system  architecture  that  the  fixed-point  data  in  the  message  are  replaced  by  float¬ 
ing  point  types,  of  which  there  are  six  (three  for  position  data  and  three  for  velocity  data). 
Based  on  the  results  in  Appendix  C,  we  use  the  following  values  for  floating  point  types: 

14.0  \isec 
365.0  M^ec 

Approximately  83  percent  of  the  total  encode/decode  time  is  spent  in  the  decode  operation. 
Applying  the  above  formula  for  the  time  required  to  encode  and  decode  a  floating  point  type 
T|p,  we  have 

Tjj,  =  6(74.0+365.0)/?  iuec 

=  2.634/?  msec 

The  above  result  indicates  that  approximately  2.5  msec  are  required  to  encode  and  decode 
the  six  floating  point  type  values  contained  in  the  track  update  message.  Of  this,  approxi¬ 
mately  0.5  msec  is  required  for  the  encode  operation,  and  2.0  msec  for  the  decode  opera¬ 
tion.  The  results  indicate  an  upper  bound  of  about  380  messages  per  second  not  counting 
other  network  effects  (physical  transmission  rates,  protocol  layer  processing)  and  also  not 
counting  the  time  to  encode  and  decode  the  ottier  data  types  in  the  message.  Furthermore, 
when  one  examines  the  number  of  track  update  messages  sent  per  second  for  each  track,  it 
is  apparent  that  the  total  processing  time  for  encode  and  decode  operations  is 
considerable.^ 

6.3.  Alternatives 

It  is  apparent  that  the  results  presented  above  and  in  Appendix  C  may  cause  concern  to 
some  system  designers.  Clearly,  the  amount  of  time  required  to  perform  data  transfor¬ 
mations  because  of  concerns  about  heterogeneity  can  be  substantial.  The  case  in  which 
the  communicating  peers  are  components  of  a  homogeneous  system  does  not  present  the 
problems  of  the  heterogeneous  case.  We  now  briefly  consider  some  of  the  issues  from  a 
system  development  standpoint. 


^For  a  network  that  can  support  a  bandwidth  of  one  megabit  per  second,  this  implies  that  the  time  spent  in 
encoding  and  decoding  the  floating  point  values  in  several  hundred  track  messages  is  equal  to  the  time  it  takes 
to  move  one  megabit  of  data.  Note  the  throughput  implications  for  system  bandwidth. 
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6.3.1.  Role  of  the  Interface  Requirements  Specification 

As  background,  let  us  note  that  systems  typically  contain  documentation  describing  the  way 
that  data  is  exchanged  among  system  components.  Such  documentation  is  often  contained 
in  an  interface  requirements  specification  (IRS),  or  an  interface  design  specification  (IDS). 
To  examine  issues  of  heterogeneity,  it  is  interesting  to  examine  the  role  of  an  IRS  in  a  par¬ 
ticular  context.  Toward  this  end,  we  define  the  following; 

•  An  IRS  is  unconstrained  if  the  specification  of  data  elements  is  independent  of 
a  particular  hardware  architecture. 

•  An  IRS  is  constrained  if  the  specification  of  data  elements  is  dependent  on  a 
particular  hardware  architecture. 

For  example,  in  an  unconstrained  form  of  the  IRS.  an  element  of  a  message  may  be  speci¬ 
fied  as  a  floating  point  type.  In  contrast,  in  the  case  of  a  constrained  IRS,  the  same  data 
type  would  be  specified  in  terms  of  a  particular  representation,  such  as  the  IEEE  format. 
Since  it  hides  implementation  knowledge  from  the  communicating  systems,  an  uncon¬ 
strained  specification  may  be  more  suited  to  use  in  heterogeneous  systems.^ 

6.3.2.  Design  Approaches 

There  are  two  basic  approaches  for  dealing  with  the  problems  of  heterogeneous  communi¬ 
cation  and  data  representation.  In  the  first  case,  one  may  want  to  apply  a  standard,  such  as 
ASN.1  BER.  One  consideration  is  to  optimize  the  procedures  that  perform  the  encode  and 
decode  operations.  As  noted  in  Appendix  C,  Ada  was  used  for  purposes  of  readability,  it  is 
clear  that  one  may  be  able  to  optimize  the  encode  and  decode  operations  by  using  as¬ 
sembler  language,  for  example.  However,  it  is  not  clear  how  much  improvement  would 
result  from  the  use  of  assembler  language. 

The  second  approach  is  to  develop  application-specific  protocols.  For  example,  a  message 
can  be  defined  in  the  following  manner: 

Message  ::= 

architecture_type; 
seq_of  {message_elements}; 
end  Message; 

where,  for  example, 

architecture_type  ;:=  {spare,  motorola68K,  Intel); 

denotes  the  hardware  architecture  that  is  used  to  represent  the  message  components  and 
the  {message_elements}  denotes  the  set  of  message  elements,  such  as  float,  integer,  and 
enumerated.  Note  that  the  above  specification  is  presented  in  an  unconstrained  form,  since 
the  representation  of  floating  point  type  is  not  defined. 


^The  fact  that  an  IRS  may  also  contain  permitted  ranges  of  values  does  not  affect  the  notion  of  constrained 
and  unconstrained  specifications. 
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To  illustrate  the  utility  of  application-specific  protocols,  consider  the  case  in  which  applica¬ 
tion  Aj  sertds  messages  to  application  Aj.  We  assume  that  the  hardware  architecture  of  A,  is 
different  from  that  of  Aj.  From  the  perspective  of  the  sending  application  there  are  two 
choices,  namely 

•  Application  Aj  encodes  the  data  in  its  native  (hardware)  representation.  This 
eliminates  the  encoding  time  required  if  a  standard,  such  as  ASN.1  BER,  were 
used.  When  application  Aj  receives  the  message,  it  performs  the  decode 
operations  from  architecture  Aj  to  its  hardware  architecture. 

•  Appiication  Aj  encodes  the  data  in  the  hardware  architecture  of  application  Aj. 

In  this  case,  when  the  message  is  received  by  Aj  there  is  essentially  no  time 
required  to  decode,  since  that  conversion  was  made  before  the  transmission  of 
the  message.® 

The  utility  of  application-specific  protocols  is  based  on  knowledge  of  underlying  hardware 
architectures.^®  This  is  in  contrast  with  the  use  of  ASN.1  BER  and  similar  representation 
schemes,  which  do  not  assume  any  knowledge  of  hardware  architectures. 

The  preceding  has  only  touched  on  several  issues  that  must  be  addressed  when  one  is 
concerned  with  data  transfer  in  heterogeneous  systems.^  ^  For  those  systems  in  which  per¬ 
formance  considerations  are  critical,  it  is  important  to  recognize  the  tradeoffs  in  the  ap¬ 
proaches  to  data  representation. 


°Note  however,  if  a  message  is  transmitted  in  a  multicast  manner  where  there  are  two  receiving  applications, 
each  of  which  has  a  different  hardware  architecture,  further  problems  must  be  addressed. 

^^is  assumes  that  message  elements  are  represented  in  naf/Ve format  for  a  particular  hardware  architecture 
and  therefore,  fixed-point  types  would  be  precluded,  for  example. 

^^We  mention  that  a  hybrid  approach  is  also  possible  that  essentially  encapsulates  a  constrained  specification 
in  an  opaque  type. 
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7.  Summary 

The  ability  of  a  real-time  system  to  satisfy  end-to-end  timing  deadlines  can  be  influenced  by 
many  factors.  One  such  factor  is  the  encoding  and  decoding  of  data,  by  an  application  task, 
which  is  then  transferred  to  a  component  of  a  distributed  system.  To  assure  that  deadlines 
can  be  met,  real-time  systems  require  timely  processing  of  application  data. 

It  is  clear  that  the  use  of  standards  in  the  development  of  real-time  distributed  systems  is  an 
important  issue.  This  report  has  examined  two  such  standards,  namely  the  Abstract  Syntax 
Notation  One  (ASN.1)  and  the  external  data  representation  (XDR),  in  regard  to  data  repre¬ 
sentation.  Each  of  these  standards  has  unique  characteristics  that  may  make  it  applicable  to 
the  real-time  domain.  Several  issues  are  pointed  out  to  help  a  designer  determine  the  ap¬ 
plicability  of  these  and  other  standards  to  the  issues  related  to  data  specification  and  repre¬ 
sentation  for  the  real-time  distributed  domain.  The  BNF  for  ASN.1  and  XDR,  as  well  as  an 
Ada  implementation  of  ASN.1  BER  encode  and  decode  routines  for  floating  point  numbers, 
are  included  in  Appendix  C. 
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Appendix  A:  ASN.1  BNF 

<«ssi.gniiwnt>  :  <typtt_asalgnaMn't>  <CR>  I  <v’alu«_«ssigiiBiant>  <CR> 

<ext«mal_typ«_xa£«r«nc«>  : :  *  <Biodula_r«£«renca>  '  . ' 
<typ«__r«£«r«nc«> 

<niodula_ra£«x«nc«>  : :«  <i.dantl£lax> 

<typ«_xtt£«xenca>  : <ld«ntl£l«x> 

<ext«xnal__yalue__ra£ax«nca>  :  <inodula_ra£aranca>  ' . ' 

<valua_xa£axanca> 

<valua_xa£axanca>  : : «  <ldantl£lar> 

<da£inad_typa>  : :«  <axtaxnal_typa_ra£axanca>  |  <idanti£lax> 

<da£lnadjvalua>  : <axtarnal^valua_^ra£aranca>  | 

<valua_j:a£aranca> 

<typa_as8lgninant>  : : «  <ldantl£lax>  ' : : <typa> 

<valua_assigniiiant>  : :«  <ldantl£lar>  <typa>  ' <valua> 

<typa>  : :«  <bulltin_typa>  |  <da£inad_typa>  |  <8ubtypa> 

^ulltlnjbypa>  : :«  <boolaan__typa>  i  <intagar_typa>  | 

•^It8trln9_typa>  |  <octafc_8tringjtypa>  |  <null_typa>  | 
<8aquanca_typa>  |  <8aqaancao£_tyi^>  |  ~ 

<8at_typa>  |  <8ato£_typa>  I  <choica__typa>  | 
<8alaction_typa>  | <taggad_typa>  |  <any_typa>  | 
<objact_ldanti£lar_typa>  I  <charactar_8trlng_typa>  | 
<u8a£ul_typa>  |  <anunaxat;adjbypa>  |  <raal_typa> 

<nainad_typa>  : :«  <i.dantl£lax>  <typa>  |  <typa>  |  <8alactlonjbypa> 

<valua>  : '^uiltinjvalua>  |  <da£inad_valua> 

'^ulltln_valua>  : : »  -^oolaan__valua>  |  <dLnt8gax_yalua>  | 
'^it8trlng_valua>  |  ~  *” 

<octat_8txing_valaa>  |  <null_j\ralua>  |  <8aquanca_valua>  | 
<8aquanc8o£_valua>  |  <8at_yalua>  |  <8ato£_valua>  I 
<cholca_valua>  |  <8alactlon_valua>  |  <taggadjvalua>  | 
<any_valua>  |  <objact_idanti£lar__yalua>  |  *” 

<chaxactar_8trlng_valua>  I  <anuniaratad_valua>  | 
<xaal_yalua>  ” 

<naii)ad_valua>  : :  =  <±dantl£iax>  <valua>  |  <valua> 

<300laan_typa>  : '  BOOLEAN  ' 
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<boolttanjvalM>  : : «  '  TRDI  '  |  '  rALSB  ' 

<lnt«g«x  typ«>  : :>  '  ZMTBGBR  '  I 

~  '  IHTBGBR  ('  <naBMd_nuiiib«r_list>  ')' 

<naiBadjauiift>«x_llst>  : :  ■  <naiMd_nuBdb«r>  | 

**  <naaMid_nuiaibttr_llst>' , '  <nafMd_nuiBb«r> 

<naawd__nuiBib«r>  :  :«>  <ldantlfler>  '  <slgMd_nuabttx>  I 
"  <id«ntifl«x>  '  ('  <de£in4Kljvalu«>  ')' 

<ttnuiMxat«d_jbyptt>  : '  BMOMBRXTBD  ( '  <«nuiMxatloa>  ' } ' 

<«nuiMxatlon>  : : «  <naiiiad^nua^x>  | 

<«niamaxatlon>  ' , '  <nain«d_nuii^x> 

<«nuMxat«d__valu«>  : :«  <ldantl£l«x> 

<x«al_typ«>  : : s  '  REAL  ' 

<x«al_yalu«>  : :«  <nuiMxlc__xeal_valua>  |  <sp«ei.al_jraal_valua> 

<nuiiiaxle_x«al_yalu«>  :  '{'  <iumtlssa>  ^asa> 

<«xponent>  '  } '  |  0 

-Oiiantls«i|>  : : »  <sl9n«djaunbttx> 

■^as«>  : 2  |  10 

<«3qpon«nt>  : :»  <slgn«d_nunibex> 

<sp«clal_xeal_value>  : '  PLUS-ZHFIMITY  '  |  '  MIMUS-IMFINITY  ' 

<bltstxlng  typa>  : '  BIT  STRING  '  \ 

'  BIT  STRING  {'  <nainedjbit_li»t> 

<naiiMdJblt_list>  : :«  <naiiiBdj3lt>  | 

<naiiiMd_bit_llst>  ' , '  <naiMd_bit> 

<naiiMd_blt>  ::b  <ld«ntl£l«x>  '  <nuab«x>  ')' 

<identi£lax>  '  <de£lned__valua>  ')' 

'03ltstxi.ng_valu«>  : '^•txlng>  |  <hstxlng>  | 

'  { '  <identl£lex_ll8t>  '  ) '  |  <«iqpty_list> 

<eiqp'ty_li.8t>  :  '{}' 

<ldantl£i8x_ll8t>  : : »  <ldentl£lax>  | 

<id«ntl£l«x^ll8t>' , '  <ldantl£lax> 

<oct«t__8txing_typa>  :  '  OCTET  STRING  ' 
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<octttt_«trlng_valu«>  : :«  I  <hstrlng> 

<nulljtyp«>  : :«  MOLL 
<nttll_valu«>  : :*  MOLL 

O^qaanctt  typ«>  : :  *  '  SBQOEMCI  < '  <*l*Mnt  typ«_list>  ' ) '  | 
'"'sigOZMCB  {)'  “ 

Jkyp«^list>  : : »  Jtyp*>  | 

<«l«Mnt_typ«_li.st>  ' , '  <«l*a«nt_typ«> 

<ttl«mant_jbyp«>  : :«  <naaad_typ«>  I 

<naMd_typ«>  '  C9T10KIXL  ' 

<naMd_typ«>  '  DSFAOLT  ' 

'  COMPOMEMTS  OT  '  <typtt> 

<s«qiMncttjvalutt>  : |  <«qpty_llst> 

<ttl«iMnt_valu«i_lls't>  : :»  <naawd_valtttt>  | 

<«l«iMnt_valtt«^list>  ' , '  <naiMd_yalutt> 

<s«qa«netto£_typ«>  '  SBQOHMCI  OF  '  <typ«>  |  '  SBQOSMCX  ' 

<*«qtt«nc«o£__valu«>  ; <valu«_li.st>  |  <wiiptyJList> 

<valu«_llst>  :  :■  <valii«>  |  <valtx«^llst>  ' , '  <iraltt«> 

<««tjtyp«>  :  *  SET  ('  <«l«BMntjbyp«^llst>  ')'  |  '  SBT  ()  ' 

<»«t_v«lu«>  'I'  <«lttiMntjiraliM_llst>  |  <«Bi^y_li«t> 

<««to£jbyp«>  : :>  '  SXT  OF  '  <typ«>  |  '  SET  ' 

<s«to£_valu«>  <valu«_llst>  |  <«qpty_llst> 

<cholc*_jbyp«>  '  CBOZCB  {'  <alt«matlv«Jbyp«_ll«t> 

<alt«zn«tiv«jbyptt_llst>  ; ;  ■  <naa«djbyp«>  | 

<mlt«xnatlv«jbyp«_ll«t>  '  <nmiamd_typm> 

<choiett_yalu«>  : :»  <naiMd_valu«> 

<s«l«ctlm»_typ«>  :  :>  <i.dttntl£l«r>  '<'  <typm> 

<s«l«etlon_valu«>  : : «  <namad_valQ«> 

<tagg«d_typtt>  <tag>  <typ«>  | 

^  <tag>  '  ZMPLZCZT  '  <typtt> 

<tag>  '  SXPLZCZT  '  <ty|w> 
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<ta9>  <olM«>  <elMSjaiuab*x>  ']' 

<olass>  ::<■  '  OMZVnSIU;.  '  I  '  APVZ.ZCATZOM  '  | 

'  mVKTE  •  I  tFSZLOH 

<olass_mifl[b«x>  : :«  <nuaib«r>  |  <d«£ia«d_vftliM> 

<tagg«d_yalutt>  : :«  <valu«> 

<any  typ«>  : :«  '  AMY  *  | 

~  '  AMY  DBrZMlD  BY  '  <ld»nti£lttx> 

<any^valiM>  : :  *  <typtt>  <valutt> 

<obj«ot_ld«ntl£lttxjbypA>  : '  G8JBCT  ZDBMTZrZBR  ' 

<obj«ct_id«ntl£l«x_yalnia>  : <obj_jLd_ooapoa*nt^llst>  ')'  | 

'  ( '  <da£la^jvalu«>  <6b  j^ld_oea^pon«nt_li.At>*~'  ) ' 

<6bj_ld__eoiqpon«nt_,llst>  :  :■  <obj_ld_ooaponttnt>  | 

<6bj_ld_ooiB|>«ittnt>  <ob ji_id_ceMponant_li.«t > 

<6bj_ld^eoflpon«nt>  : <naaMi_£oxB>  I  <n'aab«x_£oxa>'  | 
<naaii__and^nQaiMx_£oxai> 

<iiafM_£oxBi>  : :«  <ld«ati£i«x> 

<nuaft>«x^£oxn>  <nuab«x>  |  <da£lsAdjvalu«> 

<naiiMi_«nd_auBi>«x__£oxa>  : <ld«nti£iM:>  '  ('  <miai>«x^£oxai>  *)' 

<ch«xaet«x  stxlng  typ«>  'MuawxlcStxlag'  |  'PxlntablsStxing'  | 
'T^ataxStxlng'  |  'VlslblaStxing'  |  'ZASStxlng'  | 
'GxaphlcStxlng'  |  ' GanaxalStxing^ 

<chaxactax_«txlng_valaa>  ; :»  <eatxlng> 

<usa£ul_typa>  : : «  <ldanti£iax> 

<lntagaxjvalua>  : : «  <algnad_niiabax>  |  <ldantl£lax> 

—  SBBTYPB  DBCXABATZ0M8 

<si]btypa>  :  :■  ^axant_typa>  <anbtypajipao>  | 

'  SBT  '  <slxa_oonstxalnt>  '  OT  '  <typa>  | 

'  SBQUBNCB  '  <slxajoonstxalnt>  '  OF  '  <typa> 

^axant_typa>  <typa> 
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<•vbtyp•J^p•e>  : '  ('  <stibtyp«_elsastt>  ' )  ' 

<sub^yp«_olaiastt>  :  :*  <subtyptt_valu«_sttt>  <si]btyp«_y’alu«^s«t__list> 

<subtyp«_yaliM__««t_list>  :  '|'  <si]btyp«_yalutt_^sttt> 

<subtyp«_yalu«_««t_list>  |  IPSZLOM 

<«ubtyptt_valu«__««t>  : : «  <sijigltt_v«lutt>  | 

<contarn«d_subtyp«>  |  <valu«i_x«ng*>  | 

<]pttxaBitt«d_alphab«t>  I  <«lz«_constralnt>  | 
<lim«x_typ«_constraints>  ~ 

<slagl«i_vala«>  : :«  <valutt> 

<contaln«d__si]btyptt>  : '  ZMCLUDXS  '  <typtt> 

<valu«_ran9«>  : : «  <lo«fttr_j»iidpolnt>  '  . .  '  <ttppttr_(Bndpoint> 

<loirax_jBndpolnt>  : <low«r_j«ndjvalutt>  |  <loif*r_jBnd_yalutt>  <' 

<app«r_«ndpolnt>  :  <vpp«r^«nd_v«lu«>  |  '<'  <upp«r_ttnd_jiraltt«> 

<low«xjaiid^valtt«>  : : «  <valu«>  |  '  MZH  ' 

<app«xj»nd_valu«>  : :«  <vmlu«>  |  '  IflUC  ' 

<six«_^constxalnt>  '  SIZB  '  <st3btyp«_Bp«c> 

■^p«xiBlt'tttdjftlphab«t>  : '  FROM  '  <subtyp«_sp«0 

<iiin«x_typ«_constxalnta>  : :» 

'  IfXTH  COMPONENT  '  <aingl«_typ«_constralnt>  i 
'  WITH  COMPONENTS  '  <Baltlpl«_jtyp«_constxa±nt> 

<slngl«_typ«_conatralnt>  :  :*  <aubtypa(_ap«0 

<DBultlplaijtypaijconatr»lnt>  : :«  <fttll_ap«el£lc«tlon>  I 

<paxtlal_ap«cl£lcmtlon> 

<£ull_ap«cl£leatlon>  : <typa_conatrainta>  '}' 

•^axtlal_apacl£icatlon>  ...  ,  '  <typ«jconatralnta>  '}' 

<typ«_conatralnta>  : :«  <naiaad_conatxaint>  | 

<naBiad_conatx«lnt>  ' <typ«^conatralnta> 

<nain8djconatralnt>  : :*  <ld«nti£l«r>  <conatralnt>  |  <conatxaint> 

<conatxai.nt>  : :«  <valua_conatralnt>  <praaenca_conatralnt> 
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<valtM_oonatzaint>  :  :*  <siibtyp«__«p*0  |  SPSZLOII 

■^z«s«nea_coii«tzalnt>  '  PSISIMT  '  I  '  ABSEMT  '  | 

~  '  OPTZOKAL  ' I  BPSZLON 

<sign«d_nuiab«r>  <nunib«r>  |  * <auaiMir> 

<ldantl£l«z>  : :«  <vppazcaa«_,l«ttaz>  'aiora_ehazact«zs> 

<upp«zcas«_l«tt«z>  :  <RAin3B:  'A'  ..  'Z'  > 

<aorm_eiti*xmctmxa>  : : «  <l«ttar>  |  XPSZLOII 

<let:t«z>  :  <BA1I6B:  'a'  ..  's'>  |  <vpp«zoas«_latt«z>  |  | 

«llglt> 

<diglt>  ::«0tl|2|3|41S|6|7|8|9 
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Appendix  B:  XDR  BNF 

<XDR_J^ttC>  :  :•  <XDRJD«£n>  <CR>  <iBOM_XDR__Dtt£n>  <CR> 
^a)R_ptt£n>  : :*  <typ«_d«£n>  |  <cons^attt_d«£n> 

'Cnoxtt  XDR  de£n>  : : >  <xdx  d«£n>  |  SPSIDOM 


<typ«_da£n>  : : «  '  typ«<lft£  '  <d«cl>  ' ; '  I 

'  •num  '  <ldantl£lax>  <anum_body>  ' ; '  | 
'  struct  '  <ldsnti£lsz>  <stzuet__body>  ' ; '  | 
' union  '  <ldBntl£l«z>  <unlon_body>  ' ; ' 

<d«cl>  : :«  <unlt_d«cl>  <ld«ntl£laz>  I 

<£lxed_l«ngth_unlt_azzsy>  I 

<vazlsbla_l«ngth_unit_azray>  | 
<op«qua_spac>  | 

<stzlng__8pac>  I 

<vold_sp«c> 

<unlt_d«cl>  : :«  <lnt«g«z_dscl>  I 

<£loat_jdacl>  I 

<boolasn_dscl>  j 

<«nuiBBzat«d_dacl>  I 

<st3nictuza_dacl>  I 

<union_spaO  I 

<ldantl£laz> 


<lntagaz_d«cl>  : <lntagaz>  |  <un8lgnad_lntegez>  | 

<hyper_lntagar>  |  <un8lgnad_hypaz_lntagaz> 

<lntagez>  ' Int  ' 

<un8lgnod_integez>  : 'unsigned  int  ' 

■<hyper_lntegez>  : : »  '  hyper  ' 

<un8lgned_hyper_lnteger>  : 'unsigned  hyper  ' 

<£loat_decl>  : <single_£loat_decl>  | 

<double_£loat^decl> 

<slngle_£loat_decl>  : : *  ' £loat  ' 

<double__£loat_decl>  : : »  '  double  ' 

-^oolean_decl>  : 'bool  ' 

<enu]iierated_jdecl>  : : «  '  entim  '  <enum_body> 

<enuin_body>  : :  s  '  ( '  <enum  clause> 
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<oth«r_«nua_elauM>  ' ) ' 

<«nuiB_claus«>  : :«  <ldantl£l«x>  '  »  '  <lntag«r_con«tant> 

<oth«r_«num_claus«>  '  <«nua_clausa>  |  BPSIIXXI 

<stxuetuxa_d«cl>  : <CR>  'struct  '  <struct_body> 

<stxuct_body>  : ; ■  '  { '  <«truct_clau#a> 

<othar_struct_clausa>  '  } ' 

<stxuct_clauaa>  : : *  <dacl>  ' ; ' 

<othar_8tract_clausa>  : <atruct_clau8a>  |  EPSIL^ 

<uni.on_8paO  : :  >  '  union  '  <union_body> 

<union__body>  :  '  switch  ('  <idanti£iaz>  ')' 

'  {  '  <union_clausa>  <nora_‘anion_clause> 
<de£ault_clau8a>  ' } ' 

<union_clau8a>  : : •  <CR>  ' casa  '  <langth>  '  :  '  <dacl>  ' ; ' 

<DOza_union_clausa>  : : «  <union_clau8a>  |  EPSILON 

<da£ault_clau8a>  :  :<=  'de£ault  :  '  <dacl>  |  EPSILON 

<£ixad_langth_unit_azzay>  :  :<>  <unit^dacl>  <idanti£iaz> 
<£ixad__langth__8pac> 

<£ixad^langth__spac>  : : «  '  [ '  <langth>  '  ] ' 

<langth>  : :s  '^o8itiva_inta9az>  |  <idanti£iaz> 

<variabla_JLan9thjanit^arzay>  : <unitjdacl>  <idanti£iar> 
<variabla_langth_8pac> 

<vaziabla_lan9th__8pac>  :  :s'  <'  <optional_langth>  '>' 

<optional_langth>  : : »  <lan9th>  |  EPSILON 

<opaqua_spac>  :  ;>  <£ixad__langth_opaqua_spac>  | 

<vaziabla_langth_jopaqua_8pac> 

<£ixad__langth__opaqua_spac>  : 'opaqua  '  <idanti£iaz> 
<£ixad_langth__8pac> 

<variabla_lan9th_opaqua_8pac>  'opaqua  '  <idanti£iar> 
<vaziabla_langth_8pac> 

<8tzin9_8pac>  'string  '  <idanti£iar> 
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<vaxlabl«_l«ngth^«p«0 
<voi.d_sp«c>  ; :  *  '  void' 

<constan't_da£n>  : : «  '  const  '  <id«nti£lor>  '  *  ' 
<int«g«r_constnnt>  ' ; ' 

<intog«r_constant>  :  :*  <RAII6B:  -2147483647  . .  2147483647> 
'^osltiv«i__intogor>  :  <RAN6E:  1  .  .  2147483647> 

<ldttntl£i«x>  : <l«ttor>  <oth«r_chaxact«r> 

<lott«z>  ::b<BANGE:  'a'  ..  's'>  |  <lUai6B:  'A'  ..  'Z'> 
<otb«r_jchazactoz>  ::<■  <lott«r>  |  <digit>  | 

«llgit>  ::«0|1|2|3|4|5|6|7|8|9 
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Appendix  C:  ASN.1  BER  Encode  and  Decode  Routines 
in  Ada 


Performance  is  a  critical  issue  in  real-time  systems.  As  shown  earlier  in  this  report,  ASN.1  is 
a  very  general  and  powerful  technique  for  communication  in  a  heterogeneous  distributed 
system.  The  purpose  of  this  appendix  is  to  explore,  by  means  of  an  example,  the  computa¬ 
tional  cost  of  the  generality  of  the  ASN.1  BER.  We  hope  to  illustrate  exactly  what  can  be 
involved  in  the  ericoding  to  and  the  decoding  from  an  ASN.1  representation,  using  the  BER. 

We  selected  the  ASN.1  primitive  type  real  as  an  example,  as  it  appears  to  be  the  most 
complex  of  the  ASN.1  primitive  types.  We  further  chose  to  imptement  the  encode  and 
decode  routines  in  Ada.  While  more  efficient  implementations  might  well  be  possible  in 
another  language,  such  as  assembler,  we  are  more  interested  in  illustrating  the  issues  in¬ 
herent  in  the  use  of  ASN.1 .  As  Ada  is  probably  more  widely  understood  than  Sparc2  as¬ 
sembler  language,  we  feel  that  Ada  is  the  more  appropriate  choice.  Further,  we  make  no 
claims  concerning  the  optimality  of  our  code.  We  did  not  explore  alternative  Ada  implemen¬ 
tations.  It  is  therefore  quite  possible  that  more  efficient  Ada  implementations  of  the  encode 
and  decode  routines  are  possible.  Again,  our  purpose  is  to  obtain  a  general  idea  of  the  pos¬ 
sible  computational  costs  of  the  generality  of  the  ASN.1  BER. 

Our  implementation  (included  in  this  appendix)  consists  of  a  main  program  which  we  call  the 
driver.  To  decode,  the  driver  examines  an  ASN.1  encoding,  determines  the  type  and  overall 
length  of  a  component,  and  then  calls  the  appropriate  decode  routine.  To  encode,  the  driver 
determines  the  type  of  the  object  to  encode,  and  then  calls  the  appropriate  encode  routine. 
Our  driver,  encode,  and  decode  routines  are  implemented  on  a  SPARCstation  2  using  the 
self-hosted  Verdix  Ada  compiler  (VADS  6.03d). 

As  our  purpose  is  to  identify  performance  concerns  inherent  in  the  use  of  ASN.1  BER,  we 
have  accepted  certain  limitations  on  our  implementation.  For  example,  the  encode  and 
decode  routines  are  implemented  only  for  the  shortjloat  type  (32  bit  IEEE-754  float),  and 
do  not  consider  the  cases  of  NaN  (not  a  number),  or  plus  or  minus  infinity.  Only  the  ASN.1 
binary  encoding  for  reals  has  been  implemented  (a  decimal/character  encoding  also  exists). 

The  major  criterion  for  the  success  of  our  encode  and  decode  routines  is  the  ability  to  en¬ 
code  a  float,  decode  that  encoding,  and  then  verify  that  the  resulting  float  is  equal  to  the 
original  float.  This  is  done  using  both  Ada  floatjo  and  formatted  bit  displays  of  the  encod¬ 
ings  and  floats  (see  Figure  C-1 ). 


Figure  C-1 :  Testing  of  Encode  and  Decode 
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There  are  several  limitations  of  our  testing  of  the  encode  and  decode  routines.  We  have 
only  considered  "reasonable"  encodings  of  floats;  that  is,  encodings  that  use  the  minimum 
number  of  octets  to  encode  the  exponent  and  mantissa  of  the  represented  real  number. 
Another  limitation  of  our  testing  is  that  we  have  not  tested  the  encoding  and  decoding  of 
numbers  with  bases  other  than  two,  although  the  routines  are  written  to  handle  those  cases. 
Finally,  the  encode  and  decode  routines  have  not  been  tested  across  different  machines  or 
between  different  ASN.1  users. 

The  encode  and  decode  procedures  were  compiled  using  three  different  compilers;  the  self 
hosted  Verdix  6.03d  compiler,  the  Vax  Ada  V2.3-3  compiler,  and  the  XD  Ada  V1 .2-23  com¬ 
piler.  The  resultant  code  sizes  for  the  encode  and  decode  routines  are  shown  in  Table  C-1. 
It  is  apparent  that  the  assembler  code  generated  is  quite  large.  In  each  case,  the  compi¬ 
lation  was  performed  with  optimization  of  time  as  opposed  to  space. 


Function 

Vendor  A 

Vendor  B 

Vendor  C 

Encode 

130 

215 

76 

Decode 

295 

449 

236 

Table  C*1 :  Generated  Code  Size  for  Encode/Decode  Operations 


There  are  several  points  to  be  made  about  the  results  presented  in  Table  C-1 . 

•  The  results  do  not  indicate  of  the  relative  merit  of  the  compilers  tested.  The 
compilers  represent  different  target  architectures;  for  example  the  Sparc  is  a 
RISC  machine,  while  the  others  are  CISC  machines. 

•  The  generated  code  sizes  do  not  account  for  the  driver  code  that  determines 
which  routine  should  be  called.  Such  generated  code  is  expected  to  consist  of 
less  than  15  instructions. 

•  The  generated  code  sizes  do  not  include  the  elaboration  code.  Based  on  the 
number  and  types  of  local  procedures  and  declarations,  we  expect  that  the 
elaboration  cc^e  size  for  the  decode  routine  would  be  at  least  three  times 
greater  than  that  of  the  encode  routine. 

•  The  decode  procedure  contains  a  statement  that  generates  a  call  into  the  run¬ 
time  library  for  each  compiler  tested.  The  call  is  for  computing  an  integer  base 
to  an  integer  exponent.^^  An  estimate  of  the  additional  assembler  code  for  this 
operation  is  roughly  50  instructions,  increasing  the  assembler  code  for  the 
decode  operation  even  more.  No  similar  runtime  calls  were  generated  for  the 
encode  operation. 

In  view  of  the  preceding,  it  is  apparent  that  the  results  presented  in  Tabie  C-1  underestimate 
the  actual  generated  code  size.  What  we  consider  interesting  is  the  fact  that  the  code  to 
perform  the  decode  operation  is  roughly  a  factor  of  three  times  larger  than  the  code  to  per¬ 
form  the  encode  operation. 


122  **  (8  *  Exponent_Size  - 1). 
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As  an  additional  experiment,  we  compiled  our  routines  using  the  Verdix  SUN-3  to  MC68020, 
Version  6.0  cross  compiler.  We  then  tested  the  code  on  a  68020  processor  that  was 
monitored  by  a  Tektronix  DAS9200  logic  analyzer.  For  the  special  case  of  0.0,  both  the 
encode  and  decode  routines  ran  in  26  microseconds.  The  results  for  all  other  tested  real 
numbers  are  summarized  in  Table  C-2. 


Function 

Execution  Time 

Encode 

74psec 

Decode 

365  Msec 

Table  02:  Measured  Execution  Times  for  Encode/Decode  Operations 

In  any  system,  there  are  tradeoffs  between  generality  and  performance.  Frequently,  the 
more  general  a  program  is.  the  more  computation  it  must  perform.  In  our  example,  it  ap¬ 
pears  that  one  pays  a  high  price  for  the  generality  of  ASN.1.  These  figures  may  well  be  of 
concern  in  a  real-time  system.  Sensor  data,  for  example,  frequently  consists  of  multiple  real 
numbers.  The  receiver  of  such  data  would  pay  the  decode  overhead  for  each  of  the  reals 
sent. 

Note  that  part  of  the  complexity  of  our  decode  routine  stems  from  the  fact  that  the  ASN.1 
real  representation  is  not  normalized.  That  is,  one  cannot  determine,  based  solely  on  the 
number  of  octets  of  exponent  and  mantissa  in  the  ASN.1  representation,  whether  a  real  is 
representable  or  not  on  a  given  machine.  Thus  the  mantissa  must  be  processed,  and  then 
the  exponent  computed,  before  it  can  be  determined  if  the  encoded  real  can  be  represented. 
For  example,  2.0  can  be  encoded  with  a  mantissa  of  1  and  exponent  of  1 ,  or  a  mantissa  of 
10  (binary)  and  an  exponent  of  -1,  or  a  mantissa  of  100  (binary)  and  an  exponent  of  -2,  etc. 
There  is  no  limit  on  the  number  of  octets  that  can  be  used  to  represent  the  mantissa.  Hence, 
assuming  a  base  of  2  and  a  scaling  factor  of  0,  any  negative  exponent  that  can  be 
represented  in  an  ASN.1  BER  real  representation  can  be  a  valid  exponent  for  the  number 
2.0.  Since  ASN.1  BER  allows  up  to  255  octets  of  exponent,  this  amounts  to  roughly  2  ** 
2039  different  valid  representations  for  2.0.  Note  that  this  is  not  a  problem  for  XDR,  as  the 
XDR  floating  point  representation  is  normalized. 

Another  problem  we  encountered  is  that  ASN.1  does  not  provide  an  explicit  indication  of 
precision  for  reals.  As  demonstrated  earlier,  there  are  a  number  of  different  representations 
for  each  expressible  real  value.  The  ISO/IEC  ASN.1  BER  standard  [3]  states  that  the  selec¬ 
tion  of  a  particular  representation  is  at  ”...  a  sender’s  option,  and  can  be  used  as  a  broad 
indication  of  precision.”  There  is,  however,  no  way  for  the  receiver  to  know  if  the  sender  is 
using  a  particular  representation  as  an  indication  of  precision.  This  means  that  the  receiver 
(the  decode  routine)  must  have  some  understanding  of  the  sender  (the  encode  routine)  to 
properly  interpret  real  data.  This  would  require  a  protocol,  which  is  beyond  the  scope  of 
ASN.1 .  Given  the  generality  of  ASN.1 ,  we  find  this  odd. 

As  an  aside  on  the  use  of  Ada,  one  might  wonder  if  the  use  of  Ada9X  might  not  improve  the 
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encode  and  decode  routines.  Since  Ada9X  is  not  currently  available,  it  is  not  possible  to 
obtain  instruction  counts.  Ada9X  wiii  provide  certain  attribute  functions  and  procedures  for 
floats,  such  as  compose  and  decompose.  Whiie  compose  and  decompose  could  make  the 
source  code  more  readable,  it  is  not  clear  that  the  generated  object  code  would  be  more 
efficient  than  that  generated  by  Ada83. 
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with  aystwm; 

with  unchwckwd_convwzsion; 

packagw  Tazgat_Dwpttndant_D«£initiona  is 

—  Exceptions 
ASNl^Bzzor  :  exception; 

—  seised  when  the  ASN.l  encoding  cannot  be  decoded 

—  Bit,  Byte,  and  Word  Declazations 

subtype  Bit  is  integer  range  0..1; 

type  Byte  is  range  0..16#FF#; 

for  Byte' size  use  system,  stozagejunit; 

Word  :  constant  4; 

—  The  following  declarations  of  bit  arrays,  byte  arrays,  and 

—  "special"  integers  are  necessary  as  the  Encode  and  Decode 

—  routines  need  to  examine  octets,  which  soamtimes  need  to  be 

—  treated  as  bits,  while  other  times  must  be  treated  as 

—  integers. 

—  Declarations  of  assays  of  Bit 

type  Bit_Array  is  array  (0..7)  of  Bit; 

for  Bit_Arzay' size  use  system,  stozagejunit ; 
pragma  pack  (Bit^Azray) ;  ~ 

type  Nord_Bit_Array  is  array  (0. .31)  of  Bit; 

for  Wozd_Blt_Array'slse  use  4*system. stozagejunit; 
pragma  pack  (WordJBit_Array)  ;  ~ 

—  Declazations  of  arrays  of  Byte 

type  TwoJByte_Array  is  array  (0..1)  of  Byte; 

for  Two_Byte_Azray'size  use  2*system. stozagejunit; 
pragma  pack  (TwoJByte_Array) ; 

t3^  FourJByte^Azzay  is  array  (0..3)  of  Byte; 

for  Fouz_Byte_Array' size  use  4*system. stozagejunit; 
pragma  pack  (Fouz_Byte_Azray) ; 

—  Declarations  of  integers  of  "special"  lengths  for  conversion 

—  to  and  from  bit  and  byte  arrays 

type  Two_Byte_Integer  is  new  integer  range  0.. 65535; 
for  TwoJByte_Integer'size  use  2* system. stozagejunit; 
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typ*  VourJBytaJIntagttr  Is  n«w  intsgsr  ssngs  0.  .systSB.8uuc_jLiit; 
for  Foux^Byts^Zntsgsr' siss  us«  4*systsm.stosa9sjiinlt; 

—  Typ«  Daolszstlons  for  ASN.l  BKR  lUial  (Binary  Bncoding) 

typo  Bncoding_jBosdor  is 
rocord 

Cods  :  Intogor  rsngo  0..1  :«  1; 

Sign  :  intogor  rsngo  0..1; 

Bsso  :  intogor  rsngo  0 . . 3  : •  0 ; 

Scsling_Fsctor  :  intogor  rsngo  0 . . 3  : «  0 ; 

Longth  :  intogor  rsngo  0..3  :•  1; 

ond  rocord; 

for  Bncoding_Hosdor  uso 
rocord  St  siod  2; 

Codo  St  0*1ford  rsngo  0  . .  0; 

Sign  St  0*Nord  rsngo  1  . .  1; 

Bsso  St  0*Word  rsngo  2  . .  3; 

Scsling_Fsctor  st  0*1ford  rsngo  4  . .  5; 

Longth  St  0*Word  rsngo  6  . .  7; 

ond  rocord; 

for  Bncoding_Hosdor' SZZB  uso  systom.storsgojonit; 

typo  Contonts^Arrsy  is  srrsy  (nstursl  rsngo  o)  of  Byto; 

typo  Bncoding  (n  :  nstursl)  is 
rocord 

TotslJLongth  :  intogor  rsngo  0..255; 

Hosdor  :  Encoding^Bosdor; 

csso  n  is 

whon  0  s> 

null; 

whon  othors  s> 

Contonts  :  Contonts_Arrsy  (l..n); 

ond  csso; 
ond  rocord; 

prsgms  psck  (Bncoding) ; 

typo  ASMl^Encoding  is  sccoss  Bncoding; 

—  Typo  Doclsrstions  for  IBBB  floating  points 

Typo  XBBB^Flost  is 
rocord 

Sign  :  intogor  rsngo  0..1; 

Bxponont  :  intogor  rsngo  0..255; 

Hsntisss  :  intogor  rsngo  0.. 8388607; 

ond  rocord; 

pragma  psck  (ZBEE_Flost) ; 
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fox  mOMTloat  nso 
xoooxdTat  aod  2; 

Sign  at  0*1IOxd  rango  0  . .  0; 

■xpoaaat  at  0*1lozd  xanga  1  . .  8; 

Mantissa  at  0*Woxd  xanga  9  . .  31; 

and  xacoxd; 

-  Unohaokad  Convaxalons  naoassaxy  fox  Bncodo  and  Dacoda 

function  To_Two_Byta_Axxay  is 

now  unehackad_oonvaxsion  (SOOBCB  ■>  TiroJByta__Xntagax, 

XAIUSBT  «>  Two~Byta_Axxay) ; 

function  To_Foux_JByta^Axxay  is 

naw  unchackad_convaxsion  (SOOKCB  ■*>  Voux_^Byta__Xntagax, 

TXWSBT  Foux~Byta_Xxxay) ; 

function  To_FouxJByta^Xntagax  is 

naw  unchackad_convaxsion  (SOTBCB  *>  Foux__Byta_Axxay, 

XABSBT  w>  Fonx~Byta__Xntagax) ; 

function  To_Bit_Axxay  is 

naw  unchackad_joonvaxsion  (SOOBCB  ■»  Byta, 

TBBGBT  w>  Bit^Bxxay) ; 

function  To_Bit_Axxay  is  ** 

naw  uncha^ad  convaxsion  (SOOBCB  ■>  Xntagax, 

“  TABGBT  «>  1loxd_Bit_Axxay)  ; 

function  To^Bit_Axxay  is 

naw  unchackadjconvaxsion  (SOOBCB  *>  Bncoding  Baadax, 

TARSBT  »  Bit_Axxay)  ; 

function  To_Shoxt_Float  is 

naw  unchackad_oonvaxsion  (SOOBCB  *>  Woxd_Bit_Axxayr 

TBBGBT  «>  8hoxt_Float)  ; 

function  To__XBBB  is 

naw  unchackadjconvaxsion  (SOOBCB  *>  Shoxt  Float, 

“  XBBGBT  m>  XBBBjFloat)  ; 

-  Global  Oaclaxations  nacassaxy  fox  Bncoda  and  Dacoda  xontinas 

ZaxojFloat_Bncoding  :  ASMlJBncoding 

:*  naw  Bncoding  (n  *>  0) ; 

Singla_Float__Bnooding  :  ASMl_Bnooding 

:w  naw  Bncoding  (n  ■>  5); 

Zaxo_Float_Bncoding_Langtb  :  constant  :*  1; 
Singla_Float_Bncoding_Longth  :  constant  :■>  6; 


:  Gonmtmnt  :■>  1; 


—  binary  ASa.l  Bnt  ancoding 
Slngla^FloatjCoda 

—  basa  2  nuabar 

81ngla^Float_Basa  :  constant  :■  0; 

81ngla_Float__8oalingjr actor  :  constant  :■  0; 


:  constant  :*■  1; 
routine 

bit  two's  oosfplasMnt  to  a  16  bit 
with  a  23  bit  shift  Inoludad.  8aa 


:  constant  32617; 

—  For  restoring  the  InpUad  leading  one  sdsslng  froai  the  T88K 

—  nozstallsad  float. 

llantlssa_Zapllad_l  :  constant  :■  2  **  23; 

—  Constants  for  the  Decode  routine 

—  Zaf)leasntatlon  limit  on  length  of  an  encoding  which 

—  will  be  accepted. 

liaxiinnin_8ncodlog_Length  :  constant  :«  10; 

—  Zsplesmntatlon  limit  on  maxi  swim  number  of  octets  which  will  be 

—  accepted. 

Msxlmnm^BxponentjOctets  :  constant  :*  4; 

—  Number  of  bits  In  an  octet. 

Blts_Zn_jOetet  :  constant  8; 

—  Bit  positions  needed  to  extract  the  ea^onent  mantissa  from  an 

—  encoding  to  a  8hort  Float. 


BltO 

constant 

0; 

Bltl 

constant 

im 

1; 

Blt8 

constant 

im 

8; 

Blt9 

constant 

im 

9; 

Blt24 

constant 

24; 

Blt31 

emtstant 

31; 

end  Target_Dependent_peflnltlons; 


—  2  octets  of  exponent 
81ngle_Float_Length 

—  Constants  for  the  Bneode 

—  For  conversion  from  an  8 

—  two's  coepleemnt  number, 

—  Notes  section  In  Bneode. 

Conversion  Constant 
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with  Taz9ttt_p«pttndttnt_J)tt£lnltlo&s; 
us«  Taxgttt_D«p«ndant_p«£laltlon«; 

pzoottduz*  Bnood*  (Dtteodad_rioat  :  8hozt_rioat; 

Kneodsd^i^loat  :  out  ASllll_Jtoeodlng)  is 

—  Kncods  an  Slagls  Vlost  in  sn  ASM.l  zspzassntstioa  using  BKR 


Notss: 

1)  Ths  Shozt^Flost  zspzsssntstion  is  nozsnlissd. 

2)  0.0  is  s  spscisl  csss.  Ths  sneoding  contains  no  contents 
octets.  Only  the  sign  bit  in  the  header  has  SManing. 

3)  The  Shoztjrioat  eiqponent  is  8  bits  in  two's  caafplesMnt 
notation.*Zt  is  a  "bias"  representation.  That  is: 

Short_rioat  exponent  »  actual  assonant  bias, 
where,  for  the  8  bit  representation,  bias  ■  127. 

4)  The  Short^Tloat  aantissa  is  23  bits  of  binary  fraction. 
The  siantiMa  of  the  real  nus8>er  rspresented  by  the 
Short_rioat  is  1  greater  than  the  Short^Float'a  mantissa. 
That  is,  if  the  Short_Float  stores  a  swntissa  of  : 

.2345 

the  mantissa  of  the  real  nuaber  r^resented  by  that 
Short  Float  is  : 

1.2345 


5)  The  ASM.l  eiqponent  is  represented  in  an  integral  nuai>er  of 
octets  as  a  two's  cosplement  integer. 

€)  The  ASN.l  mantissa  is  r^reaented  in  an  integral  nuaber  of 
octets  as  a  binary  integer  (with  all  of  its  digits) . 

7)  Conversion  of  the  ShoirtJPloat  to  the  ASN.l  encoded 
representation  conceptually  involves  the  following: 

a)  the  conversion  of  the  Short_Float's  mantissa  to  a  binary 
integer  with  its  leading  one  restored,  (i.e.,  add  1  and 
aaaltiply  by  2  **  23) 

b)  the  conversion  of  the  8  bit  two's  compleamnt 
Short_Float's  exponent  to  the  equivalent  16  bit  two' a 
coapleamnt  integer  (necessary  since  the  mantissa  has 
been  aailtiplied  by  2  **  23,  the  es^onent  must  be 
decreased  by  23,  which  could  overflow  in  8  bits. 

8)  In  practice,  going  from  a  two's  complement  exponent  in  8 
bits  to  a  two's  coaplement  ei^nent  in  16  bits  requires  a 
change  in  bias  from  127  to  32767  (i.e.,  add  32640) . 

Further  the  conversion  of  the  mantissa  from  the  twm 
normalised  fraction  of  23  bits  to  the  ASN.l  mantissa  as  a 
binary  integer  requires  an  adjustment  of  -23.  Bence  the 
cMistant  of  32617  (ConversionjConstant) . 

9)  The  23  bit  Short_jrioat  xiantissa  is  converted  to  a  32  bit 
(blither  than  a  24  bit)  representation  due  to  alignsmnt 
problesis  the  Sparc2. 

10)  The  only  field  in  the  encoding  header  that  depends  on 
the  particular  Short^Float  being  encoded  is  the  sign.  Ne 
are  always  using  the'*ASN.l  binary  encoding  (Code  ■  1) ,  a 
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baa*  2  n\uBb*z  (Baa*  ■  0) ,  a  aeallng  factor  of  0 
(SoalingJTactox  «  0) ,  and  an  axponant  length  of  2  octota 
(Longth  ■  1) . 

Slngl*_rioat  :  mB_rioat; 

TaapJBrp  :  Two_Byt*_Int*g*r  0; 

ToiqpJTwo  :  Two_Byta_Axxay; 

T*iqp~Mantlaaa  :  Four_Byt*_Intag*r; 

T*np_Foar  :  Four_Byt*_Xrxay; 

bagin 

Slngl*__Float  :■>  To^ZBBB  (Dacodad^Float) ; 

If  Daeodadjrioat  «  0.0  then 

Z*zo_jrioat_Bncodlng . Header . Sign  : «  SingleJTloat . Sign ; 
Bncoded_Float  :«  Z*ro_Float_Bncoding; 

return; 

end  if; 

—  Move  the  8  bit  exponent  to  a  two  byte  Integer  repreaentatlon 

Tenp^Bxp  :  a  Two_Byte_Int*ger  (Singl*_Float . Sseponent ) ; 

—  Adjuat  for  the  eonveralon  from  an  8  bit  two' a  complement  to  a 

—  16  bit  two' a  coaplement,  and  alao  for  the  23  bit  ahift 

TenpJZsqp  :«  TeapJZxp  *  Converaion_Conatant ; 

—  Set  the  flelda  in  the  encoding  header 

Singl*_Float_Encoding . Header . Code 
:»  SingleJFloatjCode; 

Single_Float_Sncoding . Header . Sign 
:b  Single_Float.Sign; 

Single_Float_Bncoding . Header .Baae 
:a  Single_Float_Baae; 

Singl*_Float_Encoding . Header . Scaling_Factor 
: a  Slngle_Float_Scallngjract or ; 

Single_Float_Encoding . Header . Length 
:a  Single_Float_L*ngth; 

—  Store  the  converted  ei^onent 

TeapJTwo  :  a  Tojrwo_Byte_Arr*y  (Teap_Exp) ; 

Slngle_Float_EncodIng. Content* (1)  :a  TenpJTwoCO) ; 

Slngle_Float^Encoding .  Content  a  (2 )  :  a  T«pgp_Two  ( 1 ) ; 
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—  Convert  the  aantlssa  from  th«  23  bit  noxnallzad  fraction  to  a 

—  binary  intagar 

TanpJMantiaaa  :«  Four_Byta_Intagar  (Sin9la_noat  .Mantiaaa) ; 

—  Add  1  to  tha  mantiaaa 

if  Singlajfloat .Bxponant  >  0  than 

TaiBp_Manti8sa  :=  Tamp^Mantiaaa  ■f  Manti8sa_IiBpllad_^l; 
and  if; 

—  Stora  tha  convartad  mantissa 

Tamp_Four  ToJFour_Byta_Array  (Taiip__Mantissa) ; 
for  i  in  1  . .  3  loop 

Singla_Float_Bncoding.Contants  (i'f2)  :*  Taap_Four  (i) ; 
and  loop; 

Bncodad_Float  Singla_Float_Bncoding; 
and  Encoda; 
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with  T«ry t_J)»p«nd<nt_D»f Initions ; 
u««  Target JD«p«nd«nt_Dtt£lnltions; 

procadnxa  Dacod*  (Bncodad_l'loa‘t  :  ASNl_Znooding; 

D«codad_Float  :  out  Short_rioat)  is 

—  Decoda  an  ASN.l  RSAL  xaprasantatlon  (using  BBR)  to  a  Float 

—  Notas: 

—  1)  0.0  is  a  spacial  casa,  zaprasantad  in  tha  anooding  by  zaro 

octats  of  contants. 

—  2)  Tha  ASN.l  zapzasantation  for  raals  is  not  noznalizad.  Tha 

ancodar  of  a  zaal  stay  usa  up  to  255  octats  to  r^rasant 
tha  assonant,  and  an  unlimitad  nuaobar  of  octats  to 
zapzasant  tha  stantissa.  Hanca  it  is  not  possibla  to  daduca 
whathaz  an  ancodad  zaal  is  rapzasantabla  oz  not  on  a  givan 
machina  without  first  dacoding  it.  For  axanpla,  2.0  can  ba 
ancodad  with  a  mantissa  of  1  and  ai^onant  of  1,  oz  a 
mantissa  of  10  (binary)  and  an  assonant  of  -1,  oz  a 
mantissa  of  100  (binary)  and  an  axponant  of  -2,  ate. 

—  3)  For  our  purposes  wa  hava  limitad  tha  total  encoding  sizes 

to  10  octats,  and  tha  maxiirntm  axponant  size  to  4. 

—  4)  ASN.l  allows  for  base  2  (Haadaz.Basa  «  0),  base  8 

(Haadaz.Basa  «  1),  and  base  16  (Haadaz.Basa  ■  2)  numbers. 

—  5)  ASN.l  encodes  tha  axponant  in  a  series  of  octats  that 

follow  tha  header.  Tha  Length  field  in  tha  header 
specifies  tha  nunbar  of  octats  in  that  encoding.  If 
Haadar . Length  is  0,  there  is  1  octet  of  azponant;  if  1, 
there  are  2  octats  of  axponant;  if  2,  there  are  3  octats 
of  axponant;  if  3,  tha  first  octet  contains  tha  number  of 
following  octats  that  contain  tha  axponant  (up  to  255 
octats) .  Any  remaining  octats  contain  tha  mantissa. 

6)  Tha  ASN.l  aaqyonant  is  stored  as  a  two's  cooplament  binary 
number . 

—  7)  Tha  ASN.l  mantissa  is  stored  as  a  binary  integer. 

—  8)  Since  there  is  no  restriction  on  tha  number  of  octats  in 

tha  anantissa,  one  must  search  tha  stored  mantissa  from 
high-ordar  bit  to  low-order  bit  to  find  tha  first  one  bit 
(i.a.,  drop  tha  leading  zeros).  Since  tha  Sparc2 
Short_Float  is  normalized,  that  first  bit  will  not  ba 
stored  in  tha  decoded  float.  Tha  23  bits  following  tha 
first  one  bit  will  ba  moved  into  tha  mantissa  field  of  tha 
decoded  float.  Since  tha  ASN.l  representation  does  not 
contain  an  explicit  indication  of  precision  (i.a.,  tha 
number  of  significant  digits  in  tha  mantissa) ,  tha  Decode 
routine  can  do  no  more. 

9)  Tha  position  of  tha  first  one  bit  in  tha  siantissa  together 
with  tha  number  of  octats  that  contain  tha  mantissa 
indicate  tha  size  of  tha  real  nunbar  being  zaprasantad. 
Since  tha  decoded  float  is  nozaializad,  tha  axponant  to  ba 
stored  in  tha  decoded  float  must  ba  adjusted  accordingly. 
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—  10)  Based  on  note  8) ,  notice  that  the  encoded  float  cannot  be 
detesnined  to  be  unrepresentable  on  the  target  machine 
(the  Sparc2  in  this  case)  until  after  the  calculation  of 
the  encoded  float's  exponent. 


Base 

integer 

=  1; 

Exponent_Size 

integer 

«  0; 

Tenp_B3qp 

Four__Byte_Integer 

»  0; 

Teap_Four 

Four_Byte_Array 

s  (others  b>  16#0#  ) ; 

Index 

natural 

»  0; 

Bit__Index 

natural 

»  0; 

Tes{>_Bits 

Bit  Array 

s  (others  s>  0) ; 

Tenp__Float 

Word_Bit_Array 

■:  (others  «>  0) ; 

First_OneJBit 

integer 

»  0; 

Actual_Exp 

integer 

«  0; 

Teiip__Bit_Arsay 

Hord_Bit_Array 

B  (others  •>  0) ; 

function  Test  First  Bit  (Byte  To  Test  :  Byte; 

Bit  Value 

:  Bit) 

return  boolean  is 
TeBp__Bit_Array  :  Bit_Array; 
begin 

TeiipJBit_Jlrray  :*  ToJBit_Array  (Byte_To__Test) ; 
return  (Texnp_Bit_Array  (BitO)  »  Bit_Value) ; 
end  Test  First  Bit; 


begin 

Tenp_Float  (0)  Encoded__Float .Header .Sign; 

if  Encoded_Float . n  »  o  then 

Decoded^Float  To_Short_Float  (TenpiJFloat) ; 
return; 

end  if; 

if  Encoded_Float . Total_Length  >  Maxiimim_Encoding_Length  then 
raise  ASNl_Error; 

end  if; 

case  Encoded_Float. Header. Base  is 
when  0  s> 

Base  : «  i ; 
when  1  s> 

Base  : s  3 ; 
when  2  s> 

Base  4; 
when  3  => 

raise  ASNl_Error; 

end  case; 


CMU/SEI-93-TR-10 


59 


Ixtraot  tlM  •jqponmt  octsta  from  tha  ancodad  float 


Taaqp_roaz  (othaxa  »>  ICfOi) ; 
if  Inoodadjrioat .Baadar.Langth  <  3  than 

BxponantjSlza  Bneodad_Float .Baadar.Langth  1; 
for  1  in  1  . .  Eacponant_Siaa  loop 
Tmap^Woax  (i-f3-Bxponant__Slaa)  : «  BncodadMFloat . Contanta  (1) ; 
and  loop; 
alaa 

BxponantjSiaa  : *  intagar (Bncodadjrioat . Contanta (1) ) ; 
if  Exponant_Siaa  >  Maxiiinim_Ba^onant_Octata  than 
raiaa  ASMl_Brror; 
and  if; 

if  Bncodad_rioat. Contanta (2)  «  16#0#  than 

—  taat  firat  bit  of  naxt  octat.  if  ia  0,  arror 

if  Taat__Firat_Bit  (Encodad_Float  .Contanta  (2) ,  0)  than 
raiaa  ASNl_Brror; 
and  if; 

alaif  Encodad_Float .Contanta (2)  «  16#FF#  than 

—  taat  firat  bit  of  naxt  octat.  if  ia  1,  arror 

if  Taat_Firat_Bit  (Encodad^Float .Contanta (2) ,  1)  than 
raiaa  ASKl_Error; 
and  if; 
and  if; 

for  i  in  1  . .  Exponant_Siza  loop 
Taap_Four  (i4-3-Exponant_Siza) 

Bncodad_Float .  Contanta  (I’l^i); 
and  loop; 
and  if; 

TaxnpJBxp  : »  To_Four^Byta_Intagar  (Taiqp_Four) ; 

-  Find  firat  word  in  nantiaaa  which  containa  a  non__aaro  bit. 

indax  Bxponant__Siza  +  1; 

whila  not  (indax  >  EncodadJFloat .n)  loop 

if  Encodad_Float.Contant7( indax)  «  16#0#  than 
indax  indax  *  1; 
alaa 
axit; 
and  if; 
and  loop; 

Find  tha  firat  ona  bit  in  tha  firat  non_aaro  byta  of  tha  ASN.l 
mantiaaa  rapraaantation . 

Datarmina  ita  poaition  in  tha  aiantiaaa  (i .  a . ,  conputa 
Firat_Ona_Bit) . 

Slica  tha  23  bita  following  tha  firat  ona  bit  into  tha  dacodad 
float' a  aiantiaaa  fiald. 

if  indax  >  Encodad  Float. n  than 
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—  have  a  mantissa  of  0 
null ; 

also 

Taiip_Bits  ;s  To_Blt_Array  (Encodad_Float  .Contents  (Indax) ) ; 
Bit__Index  :  s  0 ; 

while  Taap_Bits  (Bit_Indax)  «  0  loop 
Bit__Indax  Bit_Indax  1; 
and  loqp; 

FirstjOnaJBit  :=  Bitc_ln_Octat  *  (Encodad_Float . n  -  Indax) 

+  7  -  Bit_^Indax; 

Bit_Index  :b  Blt_Zndex  -t-  1; 

for  i  in  Bit 9  . .  Bit 31  loop 
if  Bit_Indax  >  7  then 
Indax  Indax  +1; 

Tanp_Bits 

:=  To_Bit_Axxay  (Encodad_Float .Contents (Index) ) ; 
Bit__Indax  :  =  0 ; 
end  if; 

Taiiip_Float  (i)  :=  Taiip_Bits  (Bit_Indax) ; 

Bit^Indax  :=  Bit__Index  +  1; 
and  loop;  ”” 

and  if; 

—  Conputa  the  actual  value  of  the  exponent 

Actual_E3q>  :=  Base  *  integer  (Tenp_Exp) 

+  Encoded_Float . Header . Scaling_Factor 
+  Firat_One_Bit 

-  (Base  *  (2  **(8  *  Exponent__Size  -  1)  -  1)); 

—  If  the  actual  value  of  the  exponent  is  representable  on  the 

—  target  machine  (in  this  case,  the  Sparc2) ,  convert  the  value 

—  to  two's  conplement  and  store  it  in  the  decoded  float. 

if  Actual_Exp  >  Short_Float ' Machine__Emax  or 
Actual_E3qp  <  ShortJFloat '  Machine_Emin  then 
raise  ASNl_Error; 

else 

ActualJExp  :=  Actual_Exp  127; 

Teiip_Blt_Array  :  =  To__Bit_Array  (Actual_Exp)  ; 

Tesp_Float  (Bitl..Bit8)  :=  Temp_Bit_Array  (Bit24 . .BitSl) ; 
end  if; 

Decoded_Float  :=  To__Short_Float  (Teinp__Float) ; 
end  Decode; 
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with  Dmoodm: 
with  Bncod«; 

with  Taxgwt_D«p«nd«nt_JD«£lnltlons; 

us«  Targ«t_0«p«ndant_D«£lnltlons; 
with  t«xt__lo; 

with  unchttckwd_conv«xslon; 
procedure  Driver  la 

—  Declarations 
begin 

—  Initialize  the  Encoding  areas 

—  Get  the  £loat  to  test 

—  Encode  the  £loat  to  test 

—  Dunp  Encoding 

—  Decode  the  created  encoding 

—  Display  the  original  £loat 

—  Display  the  resulting  float 
end  Driver; 
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